Skip to main content

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

Yes

(Allison Mankin)

No Objection

(Bill Fenner)
(Brian Carpenter)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Mark Townsley)
(Sam Hartman)

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

(Allison Mankin; former steering group member) (was Discuss, Yes) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection (2006-01-05)
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

No Objection (2006-01-05)
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

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2006-01-01)
  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

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2006-01-03)
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.