[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
- [Ieprep] ieprep-requirements-01 - reqs 1-5 - disc… Scott Bradner
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Ken Carlberg
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Scott Bradner
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Sean Donelan
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Ken Carlberg
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Ken Carlberg
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Garrity, Jack
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Ken Carlberg
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Garrity, Jack
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Garrity, Jack
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Stuart (Stu) Goldman
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Stuart (Stu) Goldman
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Mpierce1
- Re: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Rex Buddenberg
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Garrity, Jack
- RE: [Ieprep] ieprep-requirements-01 - reqs 1-5 - … Bill Woodcock