Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
RFC 4542

Note: This ballot was opened for revision 04 and is now closed.

(Allison Mankin) (was Discuss, Yes) Yes

(Brian Carpenter) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2006-01-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Sam Hartman) No Objection

(Russ Housley) No Objection

Comment (2006-01-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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.

(David Kessens) (was Discuss) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2006-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Alex Zinin) No Objection

Comment (2006-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.