Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
RFC 4542
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
04 | (System) | Received changes through RFC Editor sync (changed abstract to 'RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet … Received changes through RFC Editor sync (changed abstract to 'RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.') |
|
2015-10-14
|
04 | (System) | Notify list changed from mankin@psg.com, jmpolk@cisco.com, jon.peterson@neustar.biz, jon@unreason.com to jon@unreason.com, jon.peterson@neustar.biz, mankin@psg.com |
|
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the Yes position for Allison Mankin |
|
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for David Kessens |
|
2006-05-17
|
04 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-05-17
|
04 | Amy Vezza | [Note]: 'RFC 4542' added by Amy Vezza |
|
2006-05-16
|
04 | (System) | RFC published |
|
2006-03-13
|
04 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-03-03
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-03-03
|
04 | Amy Vezza | IESG has approved the document |
|
2006-03-03
|
04 | Amy Vezza | Closed "Approve" ballot |
|
2006-03-02
|
04 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Discuss by Allison Mankin |
|
2006-03-02
|
04 | Allison Mankin | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin |
|
2006-03-02
|
04 | Allison Mankin | Note field has been cleared by Allison Mankin |
|
2006-03-02
|
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-03-02
|
04 | (System) | New version available: draft-ietf-tsvwg-mlpp-that-works-04.txt |
|
2006-03-01
|
04 | Allison Mankin | 03->04: ATO/US gov - add specificity: MLPP and GETs protocols are focus here, but the protocols and architectures can be used by others Section on … 03->04: ATO/US gov - add specificity: MLPP and GETs protocols are focus here, but the protocols and architectures can be used by others Section on qos choices no longer says that bandwidth is free even in overprovisioning choices. |
|
2006-03-01
|
04 | Allison Mankin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Allison Mankin |
|
2006-03-01
|
04 | Allison Mankin | [Note]: 'waiting for 04 to post...' added by Allison Mankin |
|
2006-02-10
|
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-02-10
|
03 | (System) | New version available: draft-ietf-tsvwg-mlpp-that-works-03.txt |
|
2006-01-13
|
04 | Allison Mankin | Spoke to James yesterday and talked through all the revision requirements - he had been away, then Fred had been |
|
2006-01-12
|
04 | Allison Mankin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Allison Mankin |
|
2006-01-06
|
04 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2006-01-06
|
04 | (System) | Removed from agenda for telechat - 2006-01-05 |
|
2006-01-05
|
04 | Allison Mankin | [Ballot discuss] Need to handle Alex, Russ, Bert comments, and make the text change from the Discuss that David cleared - need to clear these … [Ballot discuss] Need to handle Alex, Russ, Bert comments, and make the text change from the Discuss that David cleared - need to clear these with the WG. I took the Discuss for all these. |
|
2006-01-05
|
04 | Alex Zinin | [Ballot comment] The documents starts as a general technology discussion, and then gives so much NATO/US gov/DoD context that it makes me uneasy. It would … [Ballot comment] The documents starts as a general technology discussion, and then gives so much NATO/US gov/DoD context that it makes me uneasy. It would be good if the document either explicitly set the expectations that this is documentation of a specific architecture used by NATO/US gov/DoD by changing the title and the abstract, or the main body of the doc could be made more technology-centric and those details moved to an appendix. |
|
2006-01-05
|
04 | Allison Mankin | [Ballot discuss] Alex requires mention of MLPP/GETS in the Intro and Abstract and I'm going to handle Russ's comments - removal of HAIPE |
|
2006-01-05
|
04 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
|
2006-01-05
|
04 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from Yes by Allison Mankin |
|
2006-01-05
|
04 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens |
|
2006-01-05
|
04 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
|
2006-01-05
|
04 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
|
2006-01-05
|
04 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
|
2006-01-05
|
04 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
|
2006-01-05
|
04 | Bert Wijnen | [Ballot comment] In fugures 8, 9, 10, 11 it is using IPv4 addresses in examples that do not comply with the recommended 192.0.2.0/24 as documented … [Ballot comment] In fugures 8, 9, 10, 11 it is using IPv4 addresses in examples that do not comply with the recommended 192.0.2.0/24 as documented in RFC3330. |
|
2006-01-05
|
04 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
|
2006-01-04
|
04 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
|
2006-01-04
|
04 | David Kessens | [Ballot discuss] In section '1.6. The use of bandwidth as a solution for QoS': In places where the bandwidth can be over-provisioned to a point … [Ballot discuss] In section '1.6. The use of bandwidth as a solution for QoS': In places where the bandwidth can be over-provisioned to a point where loss or queuing delay are negligible, 10:1 over-provisioning is often the cheapest and surest solution, and by the way offers a growth path for future requirements. However, there are places in communication networks where bandwidth is not free and is therefore not effectively infinite. It is in these places, and only these places, where the question of resource management is relevant. I believe the wording here is misleading: bandwidth is never free. Adding a switch costs money in terms of capital applied but also the operational cost for installing the next best switch. Despite this, in general, overprovisioning is indeed the right and only answer to a capacity problem. The only case where this doesn't work is not the case where bandwidth is infinite but the case where it simply is physically impossible or where the cost of adding bandwidth is that prohibitive that it can be considered equal to impossible. However, even if in such cases, it is still not necessarily a justification for QoS. In many situations, this is just a clear sign that one has to abandon the technology and do something radically different. Basically, I think the the whole paragraph should go as it is way to supportive of the idea that QoS can solve your problems. What about replacing it with something very short and simple: In general, the use of overprovisioning is the most effective solution to solve QoS issues. However, this is not always possible due to cost or physical limitations. This document deals with the cases where the use of bandwidth is not a practical solution. |
|
2006-01-04
|
04 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens |
|
2006-01-04
|
04 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
|
2006-01-04
|
04 | Michelle Cotton | IANA Comments: We understand this document to have NO IANA Actions. |
|
2006-01-04
|
04 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
|
2006-01-03
|
04 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
|
2006-01-03
|
04 | Ted Hardie | [Ballot comment] Section 1.1 begins: Before doing so, however, let us discuss the problem that ETS (and therefore IEPS) is intended to … [Ballot comment] Section 1.1 begins: Before doing so, however, let us discuss the problem that ETS (and therefore IEPS) is intended to solve and the architecture of the system. It's not clear what "before doing so" refers to. Reading through it, seems like one of the main issues would be the topological placement of the server managing call placement and pre-emption, especially in relation to the resource-constrained links. It may be elided here because it is obvious or covered elsewhere, but some reference to the problem would help. |
|
2006-01-03
|
04 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie |
|
2006-01-01
|
04 | Russ Housley | [Ballot comment] The last part of the 2nd paragraph in the Abstract seems misplaced. It also appear on the Introduction, where it is very … [Ballot comment] The last part of the 2nd paragraph in the Abstract seems misplaced. It also appear on the Introduction, where it is very appropriate. A more succinct Abstract is desirable. Section 1.1.1: s/end to end capacity/end-to-end capacity/ Section 1.6: s/Type 1 encryption/military-grade encryption/ Section 2.1: s/Figure X/Figure 2/ Section 2.3.1: s/shown in Figure 2/shown in Figure 3/ Section 2.3.3: s/IPSEC/IPsec/ Section 2.3.3: What is the point of including HAIPE? It does not add any value beyond the IPsec tunnel discussion. Further, no description of HAIPE is provided. |
|
2006-01-01
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2005-12-26
|
04 | Allison Mankin | State Changes to IESG Evaluation from AD is watching by Allison Mankin |
|
2005-12-26
|
04 | Allison Mankin | Placed on agenda for telechat - 2006-01-05 by Allison Mankin |
|
2005-12-26
|
04 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin |
|
2005-12-26
|
04 | Allison Mankin | Ballot has been issued by Allison Mankin |
|
2005-12-26
|
04 | Allison Mankin | Created "Approve" ballot |
|
2005-12-26
|
04 | (System) | Ballot writeup text was added |
|
2005-12-26
|
04 | (System) | Last call text was added |
|
2005-12-26
|
04 | (System) | Ballot approval text was added |
|
2005-12-26
|
04 | Allison Mankin | Needs minor changes to address Ken Karlberg's comments, and I would like it to mention that NSIS protocols could be used in future - that … Needs minor changes to address Ken Karlberg's comments, and I would like it to mention that NSIS protocols could be used in future - that this describes what is done with presently standardized protocols. We'll fix these with Note to the RFC Editor. |
|
2005-11-15
|
04 | Allison Mankin | WGLC |
|
2005-11-15
|
04 | Allison Mankin | Draft Added by Allison Mankin in state AD is watching |
|
2005-08-23
|
02 | (System) | New version available: draft-ietf-tsvwg-mlpp-that-works-02.txt |
|
2005-07-19
|
01 | (System) | New version available: draft-ietf-tsvwg-mlpp-that-works-01.txt |
|
2005-02-08
|
00 | (System) | New version available: draft-ietf-tsvwg-mlpp-that-works-00.txt |