RE: [Ieprep] Re-charter?

"Ken Carlberg" <carlberg@g11.org.uk> Thu, 07 July 2005 13:43 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 JAA07317 for <ieprep-archive@ietf.org>; Thu, 7 Jul 2005 09:43:00 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX5p-0000Am-8c for ieprep-archive@ietf.org; Thu, 07 Jul 2005 10:11:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdr-0006Q1-Kx; Thu, 07 Jul 2005 09:42:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdq-0006Pr-5Z for ieprep@megatron.ietf.org; Thu, 07 Jul 2005 09:42:14 -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 JAA07220 for <ieprep@ietf.org>; Thu, 7 Jul 2005 09:42:11 -0400 (EDT)
Message-Id: <200507071342.JAA07220@ietf.org>
Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX50-0008WU-91 for ieprep@ietf.org; Thu, 07 Jul 2005 10:10:20 -0400
Received: from [69.138.71.61] (helo=albers) by athena.hosts.co.uk with esmtpa (Exim 4.44) id 1DqWfs-0005O4-RC; Thu, 07 Jul 2005 14:44:24 +0100
From: Ken Carlberg <carlberg@g11.org.uk>
To: 'Dennis Q Berg' <dberg3@csc.com>, 'Ieprep' <ieprep@ietf.org>
Subject: RE: [Ieprep] Re-charter?
Date: Thu, 07 Jul 2005 09:41:09 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <OFDD6D467F.29DF7330-ON85257037.0041567D-85257037.0044F899@csc.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWC8PXy3O0cDZHsSP2Fxl82JQ3FigABK9lA
X-Spam-Score: 2.0 (++)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit
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.9 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit

 
> >The IEPREP WG will address proactive and
> >reactive robustness and recovery from various outages using
> >three perspectives:
> 
> Why emphasize outages at the exclusion of congestions?

the term outages was not meant to exclude the term congestion.  
this can be resolved by using different terms such as "...recovery 
from various and substantial disruptions...", or something like that.

> >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.
> 
> This taxonomy is going to cause confusion because it tries
> to summarize in three categories what it more than three, i.e.
> 
> 
>                     Public                       Private
> --------------------------------------------------------------
> Commercial      General Public, Enterprise       Enterprise
> ---------------------------------------------------------------
> Gov't            FTS, GETS                       various
> -----------------------------------------------------------------
> Military          DSN offnet                      DSN
> 
> 
> Perhaps it would be better to start with just the twofold distinction
> of the matrix: application (commercial, civilian Gov't, military) and
> network accessibility/control (public, private).

its my impression that the Charter should not be one that covers 
all possibilities, but rather one that identifies particular area(s)
to be covered by the group at this time.  It has been expressed
in the past to have the group and its output expand its horizon to
include potential solutions -- particularly those that one comes 
across in government/military networks and intranets.  some of the
efforts from Polk/baker/pierce represent examples of these proposed
solutions that have a specific target in mind.

if there is an expansion of the taxonomy, it would seem that there would
be a corresponding need to identify corresponding drafts to be done.

> >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.
> 
> Should a charter reference a specific draft? Understand that
> this is supposed to be an example of the previous statement
> that other WGs will do the general mechanisms and requirements
> and IEPREP will do specifics that pertain to emergency preparedness -
> but it seems inappropriate to enshrine a specific example,
> especially when it is only a draft, and likely at least to need
> discussion if not being controversial in a WG charter.

there is precedent to include mention of drafts into charters
(see: http://www.ietf.org/html.charters/magma-charter.html)
At least for initial discussion, I think its beneficial to
provide an example for additional understanding, though if it
causes a lot of indigestion, the final Charter for IEPREP can 
discard mentioning works in progress.

-ken


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