Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
draft-ietf-ieprep-framework-10

4.1.3: What is EF?
 
4.4.1: There are off-the-shelf crypto chips that operate at OC-48 speeds
 
4.4.3: Mention secure PSTN phones, instead of PSTN security facilities?

Nit: MLPP mentioned but not expanded in 4.1.2.

In 1.2, the discussion of drop rate and packet size seems to presume a specific
codec is in use.  There are multiple codecs which can carry voice effectively,
and some of them are far more resilient to loss than others; those that have
step-function or continuous degredation modes, for example, may be able to
handle loss better than those without such modes.  Some discussion of this
or explanation for the choice of default codec may be required.

The document also discusses the requirements for peering between parties
that have agreed to provide ETS: 

  Domains whose peering agreements include ETS support
   must have the means to securely signal to each other a given flow's
   ETS status. They may use physical link security combined with traffic
   conditioning measures to limit the amount of ETS traffic that may
   pass between the two domains. The peering agreement must require the
   originating network to take responsibility for ensuring that only
   authorized traffic is marked with ETS priority, but the recipient
   network cannot rely on this happening with 100% reliability. Both
   domains should perform conditioning to prevent the propagation of
   theft and denial of service attacks.

I assume "Domains" here means "Service providers".  Note that in typical
cases, peering in the Internet is assymetric, using a "hot potato" algorithm-an
ISP hands traffic off to a peer at the point closest to traffic origin, and the 
recipients ISP hands it back at the point closest to its customer.  So in
the case of a customer A of ISP B in Washington, D.C. talking to a customer C of ISP D
 in San Jose, CA,, ISP B hands the traffic to C off in Washington and D carries cross-country;
the response gets handed off by D to B in San Jose, who carries cross-country.

The requirements above seem to imply either that two ISPs who have "ETS peering"
must have it every place they meet or that the ISPs backhaul ETS traffic to those
peering points where the ETS security facilities are in place.   The second approach
could involve significant delay.  The first places a significant infrastructure
 burden on the ISPs.  Discussion of these issues might be a valuable addition to the document