Re: [Ieprep] on the ieprep charter

"Howard C. Berkowitz" <> Thu, 27 July 2006 19:54 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G6Bwf-0003xA-Mc; Thu, 27 Jul 2006 15:54:57 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G6Bwe-0003x0-8P for; Thu, 27 Jul 2006 15:54:56 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G6Bwc-0002aA-Sm for; Thu, 27 Jul 2006 15:54:56 -0400
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id k6RJskWD059064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Thu, 27 Jul 2006 14:54:46 -0500 (CDT) (envelope-from
Received: (from nobody@localhost) by (8.13.6/8.13.4/Submit) id k6RJsk9p059063 for; Thu, 27 Jul 2006 14:54:46 -0500 (CDT) (envelope-from
X-Authentication-Warning: nobody set sender to using -f
Received: from ( []) by (IMP) with HTTP for <howard@localhost>; Thu, 27 Jul 2006 14:54:46 -0500
Message-ID: <>
Date: Thu, 27 Jul 2006 14:54:46 -0500
From: "Howard C. Berkowitz" <>
Subject: Re: [Ieprep] on the ieprep charter
References: <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: Please contact the ISP for more information Found to be clean
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Quoting Fred Baker <>:

> Note that I carefully separated that into three broad categories:  
> UNI, NNI, and everything else. "everything else" is within a network,  
> and I think that is the network's problem although I may have some  
> suggestions. NNI may be able to be handled by SLAs, although one  
> could argue that the entire discussion here is regarding edge  
> conditions in SLAs. It is the UNI that concerns me the most, as it  
> tends to be the place where the biggest problems occur, and where  
> problems occur at NNIs they can be treated as a variety of aggregated  
> UNI. It is the NNI and the UNI that are most in view in RFC 4542.

As a newbie to the list, but not necessarily emergency operations, there may be
additional cases. In a large disaster, it may well be that telecommunications
operating facilities may be the only available buildings with adequate backup
power, HVAC, and physical ruggedness to stay in service. I've encountered some
very ad hoc situation where emergency responders, PSAPs, etc., temporarily
operated out of telco COs and the like. 

It's not inconceivable, in such a circumstance, that such people may bring
equipment meant for UNI, in a facility with mostly NNI and other interfaces. I'd
encourage thinking about that sort of ad hoc operational requirement. 

Ieprep mailing list