RE: [Ieprep] A suggestion to the chairs
"King, Kimberly S." <KIMBERLY.S.KING@saic.com> Mon, 31 October 2005 14:36 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWamF-0004Hj-Br; Mon, 31 Oct 2005 09:36:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWamD-0004Hb-5l for ieprep@megatron.ietf.org; Mon, 31 Oct 2005 09:36:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11346 for <ieprep@ietf.org>; Mon, 31 Oct 2005 09:36:25 -0500 (EST)
Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWb0O-0001SY-F3 for ieprep@ietf.org; Mon, 31 Oct 2005 09:51:25 -0500
Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 31 Oct 2005 09:36:27 -0500
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005103109362613815 ; Mon, 31 Oct 2005 09:36:26 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <TVVJHTV7>; Mon, 31 Oct 2005 09:36:25 -0500
Message-Id: <4797F6E414C24D4A96AAC14B320BCAD7A3278B@0015-its-exmb02.us.saic.com>
From: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
To: Fred Baker <fred@cisco.com>, ieprep@ietf.org
Subject: RE: [Ieprep] A suggestion to the chairs
Date: Mon, 31 Oct 2005 09:36:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: quoted-printable
Cc:
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
Fred, I agree that it is déjà vu. And it stems from the same issue. The concrete problem statement, requirements and network context is not defined thus people argue ad nauseum about vague notions of what constitutes an emergency connection, the environment in which it is deployed, miscellaneous mechanisms in isolation, etc. Requirements should come before solutions especially when there is little agreement about the concrete problem to be solved. I understand at least one potential requirements document is in process. Things are currently too vague and vast to make progress. Kimberly -----Original Message----- From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of Fred Baker Sent: Sunday, October 30, 2005 8:15 AM To: ieprep@ietf.org Subject: [Ieprep] A suggestion to the chairs The discussion that is being had right now under the thread "Diffserv Code Point for Emergency calls" has been had roughly a zillion times since the start of the working group. We have had discussions of MLEF, of a single DSCP, and a list of others things. Look in the archive; they are there. CAC as defined in SIP/H.323/<proprietary> applies to the systems that participate in the SIP exchange, which would generally be the endpoint itself and its controlling proxy - the SIP proxy, the gatekeeper, the Cisco Call Manager, or whatever else one uses. It can accomplish certain things: if Alice calls Bob when Bob is on the phone with Carol, it can tell Bob that his wife is calling and give him the opportunity to take the call, and it can permit a pre- engineered network to do some fairly general things in terms of call counting. Step away from those fixed networks, or run that as an enterprise service running over an arbitrary collection of intermediate ISPs that don't participate in the service, and life becomes far more interesting. For example, Monday evening at the IETF there will be an ad hoc BOF discussing the GIG, which has two major components in the core - a fixed fiber optic network of arbitrarily high speed and a satellite network characterized by single-digit- megabit up/down links that have potentially large networks behind them. And we could discuss FCS etc, where we are talking about manet networks that constantly shift. Say "city of linked hot spots" and the various other kinds of networks we are building these days... BTW, what we are discussing right now is only voice on IP. We already have significant use of video on IP, and the subject matter also covers requirements for email and a variety of other applications. We need to stop traveling in circles in the ieprep discussion. Life is boring when you pass the same place over and over again without reaching the destination. The objective here, so I'm told, is to enable people like DoD, NATO, NCS, and the counterparts of NCS in 193+ countries to build a network in which a first responder or an official with certain credentials can go anywhere, jack in his laptop-or-whatever (or, in the dreams of some, commandeer a laptop-or-whatever), and use it under a policy that authorizes him to have acceptable service when nobody else is getting acceptable service. There are definitions of "acceptable service", and those of us that are working with military and civilian networks to build this - those of us for whom this is not an armchair exercise - are being held to those definitions rigorously. To do that, we need to provide tools for the likes of Verizon and BT to be able to deploy and manage those networks, and they need to work in the specialized environments that DoD and NATO build. Would those who advocate simply assigning a DSCP and being done with the discussion please explain to us how to build a service network that delivers a special service to an authorized user, one that a network operator can deploy and use, bill for the service, track and minimize fraudulent use, deliver a priority email in 7 minutes as specified, deliver both voice and video on IP with "acceptable" service as "acceptable" is defined, and so on, without authorization/ authentication and using only the very limited CAC designed for a fixed-and-specifically-tuned network? Could we get an RFC that describes that? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- RE: [Ieprep] A suggestion to the chairs King, Kimberly S.