Requirements for Emergency Context Resolution with Internet Technologies
RFC 5012
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
13 | (System) | Notify list changed from ecrit-chairs@ietf.org to (None) |
|
2008-01-09
|
13 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2008-01-09
|
13 | Amy Vezza | [Note]: 'RFC 5012' added by Amy Vezza |
|
2008-01-07
|
13 | (System) | RFC published |
|
2007-06-25
|
13 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-06-25
|
13 | (System) | IANA Action state changed to No IC from In Progress |
|
2007-06-25
|
13 | (System) | IANA Action state changed to In Progress |
|
2007-06-25
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-06-25
|
13 | Amy Vezza | IESG has approved the document |
|
2007-06-25
|
13 | Amy Vezza | Closed "Approve" ballot |
|
2007-06-22
|
13 | (System) | Removed from agenda for telechat - 2007-06-21 |
|
2007-06-21
|
13 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
|
2007-06-21
|
13 | Lisa Dusseault | [Ballot comment] Good document. I didn't understand this one though: Id9. Discovery of visited emergency numbers: There MUST be a mechanism … [Ballot comment] Good document. I didn't understand this one though: Id9. Discovery of visited emergency numbers: There MUST be a mechanism to allow the end device to learn visited emergency numbers. Motivation: Travelers visiting a foreign country may observe the local emergency number, e.g., seeing it painted on the side of a fire truck, and then rightfully expect to be able to dial that emergency number. Similarly, a local "good Samaritan" may use a tourist's cell phone to summon help |
|
2007-06-21
|
13 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault |
|
2007-06-21
|
13 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2007-06-21
|
13 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2007-06-21
|
13 | Jari Arkko | [Ballot comment] Review by Christian Vogt: This document defines a set of requirements that context resolution mechanisms should provide in support of emergency calls. Overall, … [Ballot comment] Review by Christian Vogt: This document defines a set of requirements that context resolution mechanisms should provide in support of emergency calls. Overall, this document is technically mature and easy to read. A few comments on the high-level requirements, still: - Re1 says that emergency calls should be possible independent of the existence of an application service provider. I would generalize this to saying that that an emergency call should be possible independent of whether there exists an application service provider with which the caller -- or even better: the calling UE -- currently has a valid account (e.g., with a high-enough balance). - Given that the caller might not own the UE from which an emergency call is placed, one important additional requirement should be to enable the caller to select a language when making the call. The UE may not be configured to a language the caller understands. E.g., I can envision a user trying to make an emergency call from the camera UE of another person, possibly the injured person, because the caller's own UE does not support video calls, and a video call is useful for the emergency response team to estimate the seriousness of injuries. - Re5 talks about different URIs for different protocols, yet does not mention that some protocols should be mandatory to support. As the text is now, an emergency caller may get stuck with a set of URIs none of which is supported by its UE. - The same holds for location data formats in Re7. |
|
2007-06-21
|
13 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2007-06-21
|
13 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2007-06-21
|
13 | Russ Housley | [Ballot comment] Please spell out "PSAP" the first time it is used. Please add a reference for WGS-84. |
|
2007-06-21
|
13 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2007-06-21
|
13 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu |
|
2007-06-21
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2007-06-21
|
13 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2007-06-20
|
13 | Yoshiko Fong | IANA Evaluation Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2007-06-20
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2007-06-20
|
13 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings |
|
2007-06-20
|
13 | Cullen Jennings | [Ballot comment] On Re1: It seems like the thing described in the motivation is an ASP in the definition of ASP we are using. I … [Ballot comment] On Re1: It seems like the thing described in the motivation is an ASP in the definition of ASP we are using. I found this confusing but I think I agree with the underlying use cases people have in mind. |
|
2007-06-20
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2007-06-19
|
13 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2007-06-15
|
13 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Lakshminath Dondeti |
|
2007-06-15
|
13 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Lakshminath Dondeti |
|
2007-06-14
|
13 | Jon Peterson | State Changes to IESG Evaluation from AD Evaluation::AD Followup by Jon Peterson |
|
2007-06-14
|
13 | Jon Peterson | Placed on agenda for telechat - 2007-06-21 by Jon Peterson |
|
2007-06-14
|
13 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson |
|
2007-06-14
|
13 | Jon Peterson | Ballot has been issued by Jon Peterson |
|
2007-06-14
|
13 | Jon Peterson | Created "Approve" ballot |
|
2007-06-14
|
13 | (System) | Ballot writeup text was added |
|
2007-06-14
|
13 | (System) | Last call text was added |
|
2007-06-14
|
13 | (System) | Ballot approval text was added |
|
2007-03-05
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2007-03-05
|
13 | (System) | New version available: draft-ietf-ecrit-requirements-13.txt |
|
2007-03-02
|
13 | Jon Peterson | State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Jon Peterson |
|
2006-11-05
|
13 | Jon Peterson | PROTO writeup: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version … PROTO writeup: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Hannes Tschofenig (Hannes.Tschofenig@gmx.net). The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The first version of the working group document was created based on individual submissions by a number of working group members listed in Section 11. The document took far longer than initially planned and received reviews by NENA and ETSI EMTEL (organizations that work in the emergency services environment). The requirements have been presented to the 3GPP as well. The Document Shepherd is convinced that the document is in good quality, reviewed the document several times (different versions including the last one) and believes that the document could serve as a template for requirements document developed by other working groups. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document does not require further reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the document, detail those concerns here. There are no specific issues worth mentioning. Over the lifetime of the document it was changed many times (e.g., modifications of the terminology). This, however, reflects the hard work on the document and the desire to produce a high-quality RFC rather than a problem with the document as such. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus by the working group behind the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) (1.g) Has the Document Shepherd verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. It turns out that there is an unused reference. Experimental warnings: - Unused Reference: '13' is defined on line 1028, but not referenced '[13] Wijk, A. and G. Gybels, "Framework for real-time text over IP...' We would like to remove this unused reference during AUTH48. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into a normative and informative references. This is a requirements document and there is only a single normative reference (to RFC 2119). (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document received wide acceptance within the working group. There are no aspects of fundamental controversy worth mentioning. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This is a requirements document. It places requirements on the design of the mapping protocol and the Service URN draft. The reviewers and contributors are listed in Section 11 and Section 12. As it can be seen from the long list of names the document received intensive reviews (also from other organizations working in the area of emergency services). |
|
2006-11-05
|
13 | Jon Peterson | Draft Added by Jon Peterson in state Publication Requested |
|
2006-08-28
|
12 | (System) | New version available: draft-ietf-ecrit-requirements-12.txt |
|
2006-08-07
|
11 | (System) | New version available: draft-ietf-ecrit-requirements-11.txt |
|
2006-06-12
|
10 | (System) | New version available: draft-ietf-ecrit-requirements-10.txt |
|
2006-05-18
|
09 | (System) | New version available: draft-ietf-ecrit-requirements-09.txt |
|
2006-05-03
|
08 | (System) | New version available: draft-ietf-ecrit-requirements-08.txt |
|
2006-04-20
|
07 | (System) | New version available: draft-ietf-ecrit-requirements-07.txt |
|
2006-03-08
|
06 | (System) | New version available: draft-ietf-ecrit-requirements-06.txt |
|
2006-03-02
|
05 | (System) | New version available: draft-ietf-ecrit-requirements-05.txt |
|
2006-02-22
|
04 | (System) | New version available: draft-ietf-ecrit-requirements-04.txt |
|
2006-02-03
|
03 | (System) | New version available: draft-ietf-ecrit-requirements-03.txt |
|
2006-01-03
|
02 | (System) | New version available: draft-ietf-ecrit-requirements-02.txt |
|
2005-10-24
|
01 | (System) | New version available: draft-ietf-ecrit-requirements-01.txt |
|
2005-09-06
|
00 | (System) | New version available: draft-ietf-ecrit-requirements-00.txt |