Subject: [Ieprep] problem context

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 21 Nov 2002 18:40:21 -0500

The context of "Internet Preparedness" is vast.  Some of the most heated
debates involve people with one context in mind talking to someone else with
a different one.  So, they talk past each other.  

Below is a beginning that I invite the WG to refine.  The purpose is to
facilitate problem solving.  One can state "here is the context and here is
a problem where the default situation is insufficient to solve emergency
service X".

1.	N ETS locations with access links into the same ISP where the ISP
offers CoS. Note that the particular ISP, access link bandwidth, and local
configurations can be determined in advance of the emergency.

2.	Emergency Worker accesses Internet via arbitrary connection (e.g.,
Internet Cafe).  Note that the ISP providing connectivity to the Internet
cannot be determined in advance.

3.	A predetermined network is connected to a privately managed IP WAN
over a predetermined constrained bandwidth connection (e.g., military ship
to Government owned IP network over Satellite) 

4.	A database available on the public Internet supporting emergency
services/recovery (e.g., Japan's IAA)

5.	James Polk's topology scenarios 

While each case potentially involves some form of emergency communications,
there are very different problems and ways to approach these problems. For
example, in case 1, it might be reasonable for something to track bandwidth
usage across that access link, authenticate/authorize users and apply policy
for how that bandwidth is divided up so inelastic applications perform well.
However, if you walk into an arbitrary enterprise and convince the staff
that they should let you use their network, then assuming they will have a
policy server that can authenticate you and make sure you get bandwidth over
the rest of their business users is just not too reasonable.

We need to define the problem and the context to make progress.

Kimberly
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 22 Nov 2002 07:37:35 -0500

On Thursday, Nov 21, 2002, at 18:40 America/Montreal, King, Kimberly S. 
> a different one.  So, they talk past each other.

This is without question the case.

> to Government owned IP network over Satellite)

This (3) is not an IEprep scenario.  It is a real-world military 
scenario,
just not an IEprep scenario.  And IEprep is NOT the MLPP WG.

(Aside: A suggestion I have made to the IESG is that they create a 
DiffServ Ops
WG that would be a home for evaluation/documentation of how the current
DiffServ protocol specs line up in practice with real-world operational 
networks.
Based on the output of that hypothetical WG, one could imagine that 
DiffServ specs
might be enhanced/tweaked/fixed based on real-world experience.  
DiffServ is
the obvious mechanism for item (3) above since it was used, albeit 
under another name,
some years back by US DoD to provide that capability [using Proteon 
routers if
memory serves].)

> While each case potentially involves some form of emergency 

Item (3) describes military communications rather than emergency 
communications.
Military communications might (and do) have varying degrees of urgency
and precedence, but they aren't emergency communications.  Examples of
emergency communications would be from civilian organisations such as
Fire, Police, or FEMA.  Military networks might happen to carry some
messages related to a natural disaster, but that does not make such 
networks
IEprep networks.

Ran
[email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Nov 2002 13:03:07 -0800

Ran,

[snip]
> scenario, just not an IEprep scenario.  And IEprep is NOT the MLPP WG.

I don't think I agree with your definition of an emergency, but your 
comment raises several important questions. One very important question 
is whether the scope of the IEPREP working group includes military 
emergencies/requirements. The charter is currently so vague that it can 
easily be interpreted either way. Hal seems to think the scope of the 
charter is just civilian emergencies (finally we find something for the 
two of you to agree about ;-).  Meanwhile, the ADs have blocked 
(military emergency) requirements work in SIPPING from progressing 
because "this requirements work should happen in IEPREP", and a WG item 
now in WGLC (draft-ietf-ieprep-sip-reqs) mentions both.

I don't feel there is anything especially sinister about dealing with 
military networking requirements provided the participants understand 
that the military will have to pay for their services just like 
everyone else. Certainly many of the requirements are similar, but I 
really don't care as long as we get a decision from the ADs or a 
consensus from the WG.  Whatever the outcome, I think the charter needs 
to get clarified.  My proposed text (for both possible outcomes) is 
below.

thanks,
-rohan

Civilian only:

> Effective telecommunications capabilities are imperative to facilitate 
> immediate recovery operations for serious disaster events, such as, 
> hurricanes, floods, earthquakes, and terrorist attacks. Disasters can 
> happen any time, any place, unexpectedly. Quick response for civilian 
> recovery operations requires immediate access to any public 
> telecommunications capabilities at hand. These capabilities include: 
> conventional telephone, cellular phones, and Internet access via 
> online terminals, IP telephones, and wireless PDAs. The commercial 
> telecommunications infrastructure is rapidly evolving to 
> Internet-based technology. Therefore, the Internet community needs to 
> consider how it can best support emergency management and recovery 
> operations.
>
> Three examples of emergency communications include:
>
> 1. Conveying information about the priority of specific phone calls 
> that originate in a VoIP environment through gateways to the PSTN.
>
> 2. Access and transport for database and information distribution 
> applications relevant to managing the crisis. One example of this is 
> the I am Alive (IAA) system that can be used by people in a disaster 
> zone to register the fact that they are alive so that their friends 
> and family can check on their health.
>
> 3. Interpersonal communication among crisis management personnel using 
> electronic mail and instant messaging.
>
> Initial documents will describe the problem space and its salient 
> characteristics. In particular the working group will develop a 
> Requirements for Internet Emergency Preparedness in the Internet RFC 
> which will detail the specific functions and technologies needed to 
> provide support for civilian Emergency Preparedness systems in the 
> Internet. Note that this Working Group will not address (possibly 
> similar) requirements for emergency communication in a military 
> environment. The working group may also develop a Framework for 
> Supporting Internet Emergency Preparedness in IP Telephony RFC if it 
> is determined that IP telephony requires special treatment above what 
> would be in the requirements document.
>
> The international community needs advice as to what standards to rely 
> on, in the form of a BCP. This BCP needs to identify mechanisms to 
> provide deterministic behavior of applications, mechanisms for 
> authentication and authorization, and recommendations for application 
> design with existing protocols. In the IETF considerations for 
> treatment and security of emergency communications stretch across a 
> number of Areas and Working Groups, notably including the various 
> telephony signaling working groups, Differentiated Services, Protocol 
> for carrying Authentication for Network Access (pana), and various 
> operational groups, so the IEPREP working group will have to cooperate 
> closely with these groups and with groups outside of the IETF such as 
> various ITU-T study groups.
>
> The working group will develop a BCP RFC or set of RFCs, regarding 
> operational implementation of services for Emergency Preparedness 
> using existing Internet protocols. The RFC may include identification 
> of gaps in existing protocols and requirements for use in new protocol 
> or protocol feature design. It is out of scope for this working group 
> to do protocol or protocol feature development. The working group will 
> not focus on particular national regulations.

Military too:

> Effective telecommunications capabilities are imperative to facilitate 
> immediate recovery operations for serious disaster events, such as, 
> hurricanes, floods, earthquakes, war, and terrorist attacks. Disasters 
> can happen any time, any place, unexpectedly. Quick response for 
> recovery operations requires immediate access to any public 
> telecommunications capabilities at hand. These capabilities include: 
> conventional telephone, cellular phones, privately-built emergency 
> communications networks, and Internet access via online terminals, IP 
> telephones, and wireless PDAs. The commercial telecommunications 
> infrastructure is rapidly evolving to Internet-based technology. 
> Therefore, the Internet community needs to consider how it can best 
> support emergency management and recovery operations in both civilian 
> and military settings.
>
> Three examples of emergency communications include:
>
> 1. Conveying information about the priority of specific phone calls 
> that originate in a VoIP environment through gateways to the PSTN.
>
> 2. Access and transport for database and information distribution 
> applications relevant to managing the crisis. One example of this is 
> the I am Alive (IAA) system that can be used by people in a disaster 
> zone to register the fact that they are alive so that their friends 
> and family can check on their health.
>
> 3. Interpersonal communication among crisis management personnel using 
> electronic mail and instant messaging.
>
> Initial documents will describe the problem space and its salient 
> characteristics. In particular the working group will devlop a 
> Requirements for Internet Emergency Preparedness in the Internet RFC 
> which will detail the specific functions and technologies needed to 
> provide support for Emergency Preparedness systems in the Internet. 
> The working group may also develop a Framework for Supporting Internet 
> Emergency Preparedness in IP Telephony RFC if it is determined that IP 
> telephony requires special treatment above what would be in the 
> requirements document.
>
> The international community needs advice as to what standards to rely 
> on, in the form of a BCP. This BCP needs to identify mechanisms to 
> provide deterministic behavior of applications, mechanisms for 
> authentication and authorization, and recommendations for application 
> design with existing protocols. In the IETF considerations for 
> treatment and security of emergency communications stretch across a 
> number of Areas and Working Groups, notably including the various 
> telephony signaling working groups, Differentiated Services, Protocol 
> for carrying Authentication for Network Access (pana), and various 
> operational groups, so the IEPREP working group will have to cooperate 
> closely with these groups and with groups outside of the IETF such as 
> various ITU-T study groups.
>
> The working group will develop a BCP RFC or set of RFCs, regarding 
> operational implementation of services for Emergency Preparedness 
> using existing Internet protocols. The RFC may include identification 
> of gaps in existing protocols and requirements for use in new protocol 
> or protocol feature design. It is out of scope for this working group 
> to do protocol or protocol feature development. The working group will 
> not focus on particular national regulations.

---

From: Scott Bradner <[email-masked]>
Date: Tue, 26 Nov 2002 16:30:20 -0500 (EST)

rohan sez:
>  Whatever the outcome, I think the charter needs 
> below

> . . . 

kinda a long charter  :-)

but I do not see MLPP as meaning "military" - MLPP is an ITU
standard that could be used in a number of places - I just see
it as multi-level special handling

as far as progressing something in sipping, it would seem to be good to
wait to get the ieprep doc (soon now) then have sipping
think about the problem all at once (for SIP that is)

Scott