headers
Ken Carlberg | 20 Apr 2005 23:43
Picon

re-charter?

<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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Fred Baker | 21 Apr 2005 06:07
Picon
Favicon

Re: re-charter?

On Apr 20, 2005, at 2:43 PM, Ken Carlberg wrote:
> 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).

That is it in a nutshell.
Permalink | Reply | 5 comments |
headers
Rex Buddenberg | 22 Apr 2005 00:14
Picon

Re: re-charter?

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Carlberg | 22 Apr 2005 13:39
Picon

RE: re-charter?


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

another perspective beyond best common practices would be one of
an architectural document -- something not very common within the
IETF in the past, but now more commonly seen over the past couple of
years.

-ken
Permalink | Reply | 0 comments |

Gmane