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