[Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion request

Scott Bradner <sob@harvard.edu> Sat, 02 November 2002 16:40 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08367 for <ieprep-archive@odin.ietf.org>; Sat, 2 Nov 2002 11:40:15 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2GgD107909 for ieprep-archive@odin.ietf.org; Sat, 2 Nov 2002 11:42:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA2GgDv07906 for <ieprep-web-archive@optimus.ietf.org>; Sat, 2 Nov 2002 11:42:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08356 for <ieprep-web-archive@ietf.org>; Sat, 2 Nov 2002 11:39:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA2GfFv07888; Sat, 2 Nov 2002 11:41:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA2GeVv07872 for <ieprep@optimus.ietf.org>; Sat, 2 Nov 2002 11:40:31 -0500
Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08352 for <ieprep@ietf.org>; Sat, 2 Nov 2002 11:38:02 -0500 (EST)
Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gA2Gdjaq007031 for ieprep@ietf.org; Sat, 2 Nov 2002 11:39:45 -0500 (EST)
Date: Sat, 02 Nov 2002 11:39:45 -0500
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200211021639.gA2Gdjaq007031@newdev.harvard.edu>
To: ieprep@ietf.org
Subject: [Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion request
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
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>

I'm going to follow Kimberly's lead and try to focus the discussion of
draft-ietf-ieprep-requirements-01.txt by going through it a few
requirements at a time. 

After we discuss the requirements we can go back to look at the other
material in the document.

(as an aside, it does help to number requirements as is done in the SIP
requirements - it makes it easier to talk about them and it makes it easier
for documents which talk about meeting requirements to talk about which
requirements they are talking about - I've numbered the requirements here
for ease of discussion)

As noted on the list yesterday - I think that we need to be quite careful
to specify whether we are talking about what requirements can be met on the
Internet (and private IP networks) with existing or near-term technology
and what would require significant new technology development.

I think that we also need to be careful to say what requirements can be met
with the current Internet architectural model (of autonomous
interconnecting with no particular service guarantees) and what would
require a change in this architectural model.  Along this line, we should
also be careful to say which requirements are targeted at use within an
enterprise (such as a telephone company using IP internally), at a single
ISP and which are expected to be able to be met for traffic spanning ISPs
in the open Internet.

my notes/questions at ">>"

User Requirements - 1-5

  The basic user requirements that need to be considered in providing
  emergency telecommunication capabilities to support recovery
  operations from serious disaster situations are summarized as
  follows.  Note that we assume the presence of Service Level
  Agreements in cases where user requirements cover expectations of  
  service providers:

>> see above - I'm not sure what the context is for the last
>> sentence - are we talking about the customer of a single ISP
>> using only that ISP for the emergency communications to other
>> sites on the same ISP?  If so I can see how a SLA could be 
>> used, otherwise I do not know what SLA is being referred to
   
  1  Users should be able to use public telecommunication
     resources for supporting emergency communications to help
     organize and coordinate immediate disaster recovery
     operations.
>> I do not know what is meant by "public telecommunication 
>> resources " - does this refer to the PSTN or to the Internet?

>> This seems more of a goal than a requirement.
>> Requirements should be specific enough to know if they are being 
>> met, use within an enterprise network, or within a single ISP
>> is quite different than use of the general Internet where
>> there is no guarantee where the other end of the communication
>> may be.
   
  2  Users that access emergency telecommunications service must
     be authenticated.  This should be accomplished in a timely
     manner.
>> see above, this does not seem specific enough to know if
>> its being met - for example, I can see a case where no 
>> authentication is needed over the IP part of an emergency
>> call because there are no facilities for authentication or
>> because the is no need to authenticate because there are 
>> adequate resources but that authentication might well be needed
>> with the PSTN side of a IP-to-PSTN gateway - maybe this needs
>> to say something like 'users of emergency telecommunications
>> services which require special allocation of network resources
>> must be authenticated'  
>> also there is no reason to think that authentication to one 
>> part of a communications path means authentication to the
>> rest of the path - for example, I have to go through an
>> authentication process to access part of the Harvard network
>> but that authentication is not forwarded to a IP-to-PSTN
>> gateway I might be using, nor would the Harvard authentication 
>> make any sense to the gateway 
   
  3  When networks reach traffic saturation emergency
     communication sessions should be provided with a
     higher probability of completion over non-emergency  
     communications.  We assume the presence of a service level
     agreement to accomplish this latter case. (Note: Sessions
     identified as emergency communication could be processed as
     normal traffic along with all non-emergency traffic when
     sufficient network bandwidth and resources are available.)
>> see above - this is very different within an enterprise, within
>> a single ISP and across the Internet
>> also - I would think that each ISP would decide how
>> to eet any emergency service requirement - in a few cases
>> this could mean prioritizing emergency traffic at the expense
>> of their normal customer traffic but I would expect that
>> would not be the normal case - I doubt that most ISPs
>> will be willing to starve their regular customers, who may be
>> trying to respond to the same emergency, I would expect that
>> it sis far more likely that an ISP will set aside some set
>> amount of network capacity to provide this service on
   
  4  Once an emergency communications session is established,
     the user should be able to complete the session without
     being interrupted or having the quality of the
     communications be degraded excessively.
>> I'm not sure what this means - what happens if the tail
>> circuit gets cut and there is no connectivity - or what 
>> happens if there is too much emergency traffic for the 
>> available resources?


  5  There must exist a mapping association between labels
     defined by various standards bodies.  This mapping will   
     help facilitate inter-working of services in cases where 
     gateways and networks support emergency telecommunications 
     services.
>> does this imply that the function of bridging two PSTN networks
>> over the Internet has to be able to translate between
>> two, potentially incompatible, label types?
>> it would seem to me that this would be a problem for a
>> standards organization that develops a new set of 
>> label set and not of the IP-based technology used to do 
>> bridging - i.e. it is a gateway not a transport problem

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