[Ieprep] A suggestion to the chairs

Fred Baker <fred@cisco.com> Sun, 30 October 2005 19:26 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 1EWIpE-0007Tg-Rk; Sun, 30 Oct 2005 14:26:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIpB-0007SZ-LN for ieprep@megatron.ietf.org; Sun, 30 Oct 2005 14:26:39 -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 OAA10494 for <ieprep@ietf.org>; Sun, 30 Oct 2005 14:26:18 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWDkH-00013Y-1A for ieprep@ietf.org; Sun, 30 Oct 2005 09:01:13 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2005 05:46:36 -0800
X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="358597206:sNHT27178188"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9UDkYJh007378 for <ieprep@ietf.org>; Sun, 30 Oct 2005 05:46:34 -0800 (PST)
Received: from [10.2.2.142] (sjc-vpn7-25.cisco.com [10.21.144.25]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9UDOY41014942 for <ieprep@ietf.org>; Sun, 30 Oct 2005 05:24:35 -0800
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2801667743@proton.jnpr.net>
References: <9BD5D7887235424FA97DFC223CAE3C2801667743@proton.jnpr.net>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <52DFF95F-3121-432D-9020-0AB3EF678052@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Sun, 30 Oct 2005 08:14:48 -0500
To: ieprep@ietf.org
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1; q=dns; l=2818; t=1130678675; x=1131110875; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:A=20suggestion=20to=20the=20chairs| From:Fred=20Baker=20<fred@cisco.com>| Date:Sun,=2030=20Oct=202005=2008=3A14=3A48=20-0500| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=n7cjNyq7mPcYtWx5EooCEpGxUUxfHSk99kjJPTyuk8L8VG08aPutyVy7jsdEo1Gw8jTf7+5/ b9kCprxrrRuTAroGgoj6LE3WsipwcL+3UzPQumW8k+putRVCwrvHd+wDbvXZXirY1PB3WG0rhYX cn8psAdV22PpV5Gk0y8g8aNc=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Subject: [Ieprep] A suggestion to the chairs
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

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