Re: [Ieprep] Re-charter?time slot?

Janet P Gunn <jgunn6@csc.com> Fri, 01 July 2005 19:41 UTC

Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04428 for <ieprep-archive@ietf.org>; Fri, 1 Jul 2005 15:41:05 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRnv-0000Bg-IN for ieprep-archive@ietf.org; Fri, 01 Jul 2005 16:08:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRMN-0008HY-Rm; Fri, 01 Jul 2005 15:39:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRML-00086M-Up; Fri, 01 Jul 2005 15:39:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04238; Fri, 1 Jul 2005 15:39:29 -0400 (EDT)
Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRmN-0008VG-Br; Fri, 01 Jul 2005 16:06:27 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j61JdW1R012389; Fri, 1 Jul 2005 15:39:32 -0400 (EDT)
In-Reply-To: <OF643187F4.8FB8F0E5-ON85257031.0053D965-85257031.0053FCC1@csc.com>
Subject: Re: [Ieprep] Re-charter?time slot?
To: Dennis Q Berg <dberg3@csc.com>
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <OF0FF913EA.B1316C24-ON85257031.006B7449-85257031.006BFF03@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Fri, 01 Jul 2005 15:37:38 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/01/2005 03:39:16 PM
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 410b68b37343617c6913e76d02180b14
Cc: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, ieprep-bounces@ietf.org, "Jon Peterson (jon.peterson@neustar.biz)" <jon.peterson@neustar.biz>, "Ieprep (ieprep@ietf.org)" <ieprep@ietf.org>, sob@harvard.edu
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437




According to the IETF web site,
July 5, Tuesday is the  closing date for Working Group and BOF initial
scheduling 17:00 ET (21:00 GMT)
July 11, Monday is the  Cutoff date for requests to reschedule Working
Group and BOF meetings 09:00 ET (13:00 GMT)
July 18, Monday is the closing date for Final Working Group and BOF
scheduling 17:00 ET (21:00 GMT)

So if there is a need for a longer slot, the request would need to be
submitted very soon.

Janet


----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




                                                                                                                            
                      Dennis Q                                                                                              
                      Berg/FED/CSC             To:      "King, Kimberly S." <KIMBERLY.S.KING@saic.com>                      
                      @CSC                     cc:      ieprep-bounces@ietf.org, "Jon Peterson                              
                      Sent by:                 \(jon.peterson@neustar.biz\)" <jon.peterson@neustar.biz>, "Ieprep            
                      ieprep-bounces           \(ieprep@ietf.org\)" <ieprep@ietf.org>, sob@harvard.edu                      
                                               Subject: Re: [Ieprep] Re-charter?                                            
                                                                                                                            
                      07/01/2005 11:17                                                                                      
                      AM                                                                                                    
                                                                                                                            








Just a logistic note to start.  For discussion of the charter, and if there
are also going to be any presentations, it strikes me that an hour is a bit
short.  Would it be possible to schedule a slot of at least an hour and a
half?

Dennis


----------------------------------------------------------------------------------------


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------






                      "King, Kimberly

                      S."                      To:      "Ieprep
(ieprep@ietf.org)" <ieprep@ietf.org>
                      <KIMBERLY.S.KING         cc:      sob@harvard.edu,
"Jon Peterson \(jon.peterson@neustar.biz\)"
                      @saic.com>               <jon.peterson@neustar.biz>

                      Sent by:                 Subject: [Ieprep]
Re-charter?
                      ieprep-bounces



                      06/30/2005 10:24

                      AM








Scott and I have asked for a 1 hour meeting slot at
the Paris IETF meeting to discuss a possible re-charter
of ieprep.  A provisional new charter is included below.

Kimberly


*****************************************
Draft revision
Internet Emergency Preparedness (ieprep) Charter

Description of Working Group:

Effective telecommunications capabilities are imperative to
facilitate immediate recovery operations for serious
disaster events including natural disasters (e.g.,
hurricanes, floods, earthquakes) and those created by man
(e.g., terrorist attacks, combat situations or wartime
events).  In addition, related capabilities should be usable
in normal command and control operations of military
services, which often have timeliness requirements even in
peacetime.  The IEPREP WG will address proactive and
reactive robustness and recovery from various outages using
three perspectives:

1. A commercial (i.e., or public) telecommunications
infrastructure

2. A governmental/military telecommunications infrastructure
that may retains sole ownership and administration of its
own resources

3. A governmental/military telecommunications infrastructure
that combines private resources and leverages public
infrastructure.  This scenario may be subject to local
policies, laws, and regulations.

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, 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.

Potential disasters for governmental/military
infrastructures can extend beyond what might be experienced
by the commercial/public sector and can be anticipated to
some degree.  Thus, proactive mechanisms to address would-be
outages are required for these scenarios.

The IEPREP WG will work on these three perspectives
(commercial, governmental/military, and the combination) and
synergize common mechanisms and requirements into other
groups where possible, while maintaining a separate track of
IEPREP documents for the unique mechanisms and requirements
of each perspectives.

Now that the initial documents describe the broad problem
space and its salient characteristics, new efforts will
focus on specific requirements and solutions such as those
pertaining to the governmental/military sector.  One
document exists in the Transport Area working group of
interest to IEPREP that could satisfy a governmental
framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX.  This
document will progress to completion in that WG, yet be the
basis of more work in this IEPREP WG.  Some additional
efforts on the governmental/military track within IEPREP
will focus on this TSVWG document, analyze gaps, and provide
input where needed.

The following are four specific examples that can satisfy
the interests of governmental/military (and potentially,
commercial/public) emergency communications:

1. Conveying information about the priority of specific
flows (or sessions) that originate in a VoIP environment.
This could include a requirements effort to describe
extensions to NSIS or RSVP. Requirements for NSIS would be
forwarded to the NSIS working group. Requirements for RSVP
could be forwarded to tsvwg or worked on in IEPREP.

2. Nested VPNs require special considerations for routing
and QoS if nodes in the path that make these decisions
generally have limited information.

3. Some countries require civil networks to preempt sessions
under state circumstances, and preemption is considered an
absolute requirement in governmental networks in most
countries. Unless implementation of these requirements can
be objectively shown to threaten network health (via
simulation or in operations), then the requirement needs to
be considered by IEPREP and specific solutions must be
developed.

4. Non-real-time applications require measures of QoS and
other preferential treatments, as voice will not be the only
application used by IEPREP.

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, Protocol for carrying
Authentication for Network Access (pana), the open Transport
Area for path-coupled signaling and various operational
groups. IEPREP will cooperate closely with these groups and
with those outside of the IETF such as various ITU-T study
groups.


If there is an existing WG that can discuss the requirements
for extending their protocol or mechanism, IEPREP will
generate only a requirements document for that group to
discuss.

If there is not an existing WG that can discuss the
requirements for extending their protocol or mechanism,
IEPREP will prepare requirements and discuss the extension
of that protocol/mechanism or protocols/mechanisms within
IEPREP.


Goals and Milestones:

Done   Submit initial I-D of Requirements

Done   Submit initial I-D of Framework

Done   Submit initial I-D of Recommendations BCP

Done   Submit Requirements I-D to IESG for publication as an
       Informational RFC

Done   Submit Framework I-D to IESG for publication as an
Informational RFC

Dec 03 Submit Recommendations I-D to IESG for publication as
a BCP

Oct 05 Submit an initial I-D of Emergency Threats Analysis
of Government/Military Networks

Dec 05 Submit an initial I-D of Differences between GETS and
MLPP Networks

Feb 06 Submit an initial I-D of Requirements of
Government/Military Networks

Mar 06 Submit an initial I-D of Considerations for potential
solutions of Government/Military Networks

Apr 06 Submit an initial I-D of Mechanisms to be used by
       Government/Military Networks

Oct 05 Submit final I-D of Emergency Threats Analysis of
       Government/Military Networks to IESG as Informational
RFC

Feb 06 Submit final I-D of Requirements of
Government/Military Networks to IESG as Informational RFC

Apr 06 Submit final I-D of Mechanisms to be used by
       Government/Military Networks to IESG as BCP RFC

The working group will discuss re-chartering if additional
efforts are agreed upon by the WG (for example, work items
related to protocols outside existing WGs).

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep




_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep



_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep