RE: A suggestion to the chairs
"King, Kimberly S." <[email protected]> Mon, 31 Oct 2005 09:36:01 -0500
| Newsgroups | gmane.ietf.ieprep |
|---|---|
| Message-ID | <4797F6E414C24D4A96AAC14B320BCAD7A3278B@0015-its-exmb02.us.saic.com> |
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: [email protected] [mailto:[email protected]] On Behalf Of Fred Baker Sent: Sunday, October 30, 2005 8:15 AM To: [email protected] 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 [email protected] https://www1.ietf.org/mailman/listinfo/ieprep