Re: re-charter

I think rechartering the ieprep wg is a good idea. In rechartering, I would
like the group to consider the following.

Based upon testing of IP/GSTN interoperability under conditions of
congestion, there are a number of IP network requirements and mechanisms
needed to ensure a GETS-like service works across a congested IP network.
For example, fidelity of DTMF tones for PIN authentication is an issue at
high utilizations.

The requirements associated with emergency communications (e.g., a
GETS-like service) fall into four broad categories:

1. Signaling. Signaling requirements can be divided into two types: (a)
Signaling a request for emergency communications to an authentication /
authorization entity for approval, and (b) Signaling an authorized /
authenicated request from the source to destination. Within the IP network,
SIP was found to be resilient in the face of congestion, so no distinction
may be required between the two signaling types. However, the delays
associated with SIP under heavy congestion impacted its successful
interoperation with SS7 signaling in the PSTN.

2. Resource Provisioning. Providing the necessary resources for
authenticated emergency communications. With G711 codecs, VoIP was found to
be intelligible up to an offered load of 150% of the bottleneck link
capacity. Thus a Call Admission Control mechanism that allows for
"oversubscription" for emergency communications may be appropriate (e.g.,
CAC set to 80% of link capacity, with emergency communications allowed an
additional 10% of link capacity). If oversubscription is not acceptable,
guaranteed bandwith is also possible. With the Cisco routers we were using,
we could allocate bandwidth in the EF queue for emergency communications
and for normal traffic. In this latter case, some sort of marker (e.g.,
DSCP) may be needed for emergency traffic, but a unique per hop behavior
may not be needed.

3. Security. Issues include authentication within the IP network and across
network  boundaries. In particular, if a GETS-like service is authenticated
in the GSTN through DTMF tones transmitted across the IP network (as is
currently done), there are issues of PIN intercept and PIN transmission
errors associated with delayed and dropped packets at high utilizations.
RFC 2833 and the KeyPad Markup Language (KPML) may provide solutions. A
second issue concerns inter-domain trust to allow "prioritization" of
emergency communications end-to-end, both between IP domains, and between
IP and GSTN domains.

4. Network engineering and provisioning "best practices." For example, for
IP/GSTN interoperation, the number of SIP retries should be set to "x."

While the documents already produced by the ieprep wg address, at varying
levels, many of these areas, there are additional "GETS-like"
service-unique requirements that are not documented. It is likely that a
majority of these additional requirements can be satisfied by using the
mechanisms (being) developed by the other working groups.

As such, I believe the charter should allow for the creation of additional
"to be specified" I-D documents by the working group. If this is allowed
and the working group is rechartered, then I am willing to work in the
group to define and create the appropriate documents discussing the
"GETS-like" requirements, mechanisms and best practices.