Re: [Ieprep] re-charter?

Rex Buddenberg <budden@nps.navy.mil> Thu, 21 April 2005 22:16 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22757 for <ieprep-archive@ietf.org>; Thu, 21 Apr 2005 18:16:14 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOk9a-00073h-ER for ieprep-archive@ietf.org; Thu, 21 Apr 2005 18:28:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjwB-0002S1-P3; Thu, 21 Apr 2005 18:14:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjw9-0002Rw-TX for ieprep@megatron.ietf.org; Thu, 21 Apr 2005 18:14:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22544 for <ieprep@ietf.org>; Thu, 21 Apr 2005 18:14:14 -0400 (EDT)
Received: from ellis.ad.nps.navy.mil ([131.120.18.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOk7d-00071Z-UF for ieprep@ietf.org; Thu, 21 Apr 2005 18:26:10 -0400
Received: from antony ([131.120.179.249]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 15:14:12 -0700
Subject: Re: [Ieprep] re-charter?
From: Rex Buddenberg <budden@nps.navy.mil>
To: Ken Carlberg <carlberg@g11.org.uk>
In-Reply-To: <200504202144.RAA24596@ietf.org>
References: <200504202144.RAA24596@ietf.org>
Content-Type: text/plain
Date: Thu, 21 Apr 2005 15:14:12 -0700
Message-Id: <1114121653.13043.45.camel@antony>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-2)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Apr 2005 22:14:12.0974 (UTC) FILETIME=[72DD70E0:01C546BF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: ieprep@ietf.org
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.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit

Ken,

Thanks for a thoughtful note ... and not too long.

When you apply any technology, and certainly internet technology, to the
problem of emergency services, a bunch of things pertain, not just the
technology ... or the protocols.

In my experience, the internet protocols are pretty good for emergency
services.  The critical issues are things like provisioning -- ensuring
enough elimination of single points of failure that the system doesn't
conk out under stress.  Is not a protocol issue at all -- indeed, the
very design of IP waaaay back when v4 was first set down did the
trick.  

To put this in academic terms, there are three principles of high
availability engineering:
	- elimination of single points of failure
	- reliable crossover
	- prompt detection of failures as they occur.

The first is a provisioning problem, not a protocol one.  The second is
a protocol design one, but been done for years.  The third is solved at
the protocol level by SNMP, but is also a provisioning one (ya gotta
implement it, and at appropriate levels of granularity).

So if an emergency services planner (no, not always an oxymoron) is
looking for a one-stop shop, he won't find it in the RFCs and won't find
it in the current IEPREP charter.  Same problem turned around to a
slightly different view: if the only thing we concentrate on is
protocols (my understanding of the current charter), then we miss some
really important parts of the problem and ones that are not very
susceptible to protocol solutions.  


I'd like to see the charter broadened to include best practices -- a
one-stop how-to kit for planners working emergency services comms (which
should include just about every municipality in the land -- yours too,
Ken).  


On Wed, 2005-04-20 at 17:43 -0400, Ken Carlberg wrote:
> <warning: this is a bit lengthy and kind of resembles a noel-gram :) >
> 
> a couple of months ago there was a brief thread on this list that
> discussed the possibility of rechartering IEPREP.  currently, the
> charter focuses the attention of IEPREP to requirements and
> framework documents.  
> 
> however, it had been pointed out in that re-chartering thread that 
> there are several individual drafts floating in the I-D ether that 
> have varying degrees of relevance to the subject of emergency 
> communications, and yet don't seem to have a home.  at both the 
> washington-ietf and the minneapolis-ietf (and actually earlier 
> meetings if one wants to include some of the rsvp extention work) 
> there were attempts to discuss these drafts at the TSVWG meetings, 
> but there wasn't much reaction.   Joe Touch's comment at each 
> meeting (my paraphrasing) that the "silence was deafening" seemed 
> to capture the moment.  on the other hand, it also seemed that a 
> considerable chunk of the material that Fred Baker discussed 
> (ie, the MLPP drafts) was quite outside of the interest of the 
> usual suspects that attend TSVWG.  there seemed to be considerably 
> more discussion on Fred's and James's material at the San Diego 
> IETF meeting than at the DC and Minneapolis combined -- the 
> minutes of each meeting may bear this out, but then that is also 
> dependent on who takes the minutes.
> 
> while I can't speak for Fred or James as to the reason their MLPP
> drafts have been forwarded to TSVWG (one assumes because it is the
> catch-all for transport area drafts that have no other home), I can
> certainly see that the current charter of IEPREP prevented their
> inclusion in IEPREP (because it only deals with requirements and
> frameworks).
> 
> so that takes us to the subject of this long winded email.  
> 
> In the old charter thread, James suggested (words to the effect of) 
> we should explore rechartering IEPREP so that it can now address the 
> subject of solutions.  its my understanding that some folks at the 
> Minneapolis IETF discussed this topic in the hallways, but I am in the 
> dark as to the ultimate conclusions.  soooooo, I'd like to revisit this
> discussion on the list.  specifially, 
> 
>    - what are the objections (if any) to expanding the charter?
>      (and if the chairs/ADs have objections, now is the time to
> 	chime in :-)
>    - assuming we have rough consensus of exploring the subject of
>      re-chartering, what should the new charter say?
> 
> Note, and this is a whopper of a caveat!  All of us need to be in
> agreement that *proposed solutions* could only be considered in 
> IEPREP where no other *applicable* active working group exists.
> 
> Note #2...Perhaps a starting point for any discussion of a proposed
> new charter is agreeing on what is considered a solution :-)
> 
> comments?
> 
> -ken
> 
> 
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
-- 
b


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