Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
RFC 4542
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Allison Mankin; former steering group member) (was Discuss, Yes) Yes
(Alex Zinin; former steering group member) No Objection
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.
(Bert Wijnen; former steering group member) No Objection
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.
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
(David Kessens; former steering group member) (was Discuss) No Objection
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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.
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
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.