From mailman-owner@ietf.org Mon Apr 1 06:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20348 for ; Mon, 1 Apr 2002 06:50:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17121 for ; Mon, 1 Apr 2002 06:51:00 -0500 (EST) Date: Mon, 1 Apr 2002 06:51:00 -0500 (EST) Message-Id: <200204011151.GAA17121@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ieprep-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ieprep-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-web-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org fPSM https://www1.ietf.org/mailman/options/ieprep/ieprep-web-archive@ietf.org From ieprep-admin@ietf.org Mon Apr 1 11:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04403 for ; Mon, 1 Apr 2002 11:45:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20926; Mon, 1 Apr 2002 11:43:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20894 for ; Mon, 1 Apr 2002 11:43:10 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04353 for ; Mon, 1 Apr 2002 11:43:07 -0500 (EST) Received: from [24.28.197.67] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1330984; Mon, 01 Apr 2002 11:42:57 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] multicast To: Dean Bogdanovic , "Marshall Eubanks" Cc: Sean Donelan , "Nguyen, An" , "Gunn, Janet NE" , ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 01 Apr 2002 11:42:57 -0500 Message-ID: In-Reply-To: <200204010216.g312Gpq10410@volta.mazunetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Sun, 31 Mar 2002 21:16:51 -0500 Dean Bogdanovic wrote: > > (At the time I was not part of instant messengering, so > I > > made no direct observations of that communications > channel. > > I would be curious to hear of reports on its use and > > usability in the crisis.) > > I can tell from own experience and from other people that > I have heard > that IM was working well. I can not say that was the > general case, but > in cases that I know, it was working well. I believe that > IM could be > a good solution for emergency communications (either data > or voice), > expecially if endusers can establish sessions without a > middlebox and > that, from a technical perspective is possible today. It > requires end > user device to be more detailed configured, but it makes > it pretty > independent as long the basic infrastucture (IP > connectivity) is > available. > Using SIMPLE today (I am not saying that is the best > solution, but > something to start with), endusers can configure without > a middlebox > and establish end to end sessions as long the IP > communications is > present. The enduser device needs to have all necessary > configuration > available and that device is pretty independent. > This makes the emergency communications pretty hard to > stop by DoS > attacks, because it is distributed without a central > point of failure > (no addtional services are needed, but usefull if > available). > > > > > Avi Freedman of Akamai told me that the Akamai > > infrastructure functioned well on 9/11, so the problems > that > > I and many others noticed were presumablely between > sources > > and caches. > > Akamai infrastructure works well for static content, but > there are > problems for dymanic content delivery or when there are > lot of changes > at the source, as stated above. > > > The technology exists to set up video channels on the > > Internet between any emergency services that wish it. > It > > seems clear to me, based on what happened on 9/11, that > > multicasting should be given serious consideration for > the > > transport for these channels. If these are set up and > put > > into use now, they can be available during the next > crisis. > > It seems to me that this fits squarely within the > charter of > > the working group. > > > > Multicast is a nice technology and I agree that it should > be > considered, but it is also stopable with good designed > DoS attacks > (delivery comes from few sources, so those sources need > good > protection. I do not believe that akamaizing would help, > because of > dynamic nature of content delivery). That is basically my experience. As for DOS attacks : There is the generic problem : If the foo fire department is sourcing content, that is coming from some FFD computer which is subject to DOS. (This is true even if the content is being spread about in a P2P fashion, as it has to come from somewhere.) This is problem, I would submit, for any content. There is the transport specific problem : Multicast is subject to a number of DOS attacks, as described in a presentation I gave to the MBONED WG at IETF 51 http://www.multicasttech.com/papers/ietf_51_mboned_tme.{pdf,ppt} The adoption of SSM will remove most of these weaknesses. However, I regard this as a difficult problem for any Internet based emergency communications - especially as, if the DOS attacks are part of a larger assault, they may take novel forms. Difficult is not the same as insurmountable, though. Marshall > > --br > > Dean _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 12:10:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06061 for ; Mon, 1 Apr 2002 12:10:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23501; Mon, 1 Apr 2002 12:07:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23465 for ; Mon, 1 Apr 2002 12:07:39 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05728 for ; Mon, 1 Apr 2002 12:07:36 -0500 (EST) Received: from [24.28.197.67] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1331005; Mon, 01 Apr 2002 12:07:34 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] multicast To: goldmans@agcs.com, "Nguyen, An" Cc: "'Marshall Eubanks'" , "Gunn, Janet NE" , ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 01 Apr 2002 12:07:34 -0500 Message-ID: In-Reply-To: <3CA4F5BD.FA2A7486@agcs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Fri, 29 Mar 2002 16:16:13 -0700 "Stuart (Stu) Goldman" wrote: > How large should such a block be? > Dear Stu; I do not know. I would guess that a /20 would be a good start. I worry that what ever is picked will turn out to be inappropriate. I am going to talk to the EMT people in Fairfax County, VA (one of the most traveled in the world, and conveniently close) and see what the responsible people there think that the need is and what they think of these ideas. People might be interested in the waves of technical suggestions washing over Gov. Ridge and the OHS : http://www.washingtonpost.com/wp-dyn/articles/A41390-2002Mar30.html My understanding is that getting thorugh the clutter is hard right now. Regards Marshall Eubanks > "Nguyen, An" wrote: > > > Setting aside a block of class D addresses for > emergency multicast traffic > > is needed. You have my vote on it. > > > > Regards, > > > > An Nguyen > > > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@multicasttech.com] > > Sent: Friday, March 29, 2002 1:37 PM > > To: Gunn, Janet NE; 'Marshall Eubanks'; Nguyen, An > > Cc: ieprep@ietf.org > > Subject: Re: [Ieprep] multicast > > > > On Fri, 29 Mar 2002 13:18:01 -0500 > > "Gunn, Janet NE" wrote: > > > What, if any, priority mechanism would be appropriate > > > with multicast? > > > > Hello; > > > > The method that I intend to recommend is to have IANA > set up > > an emergency allocation block from the RFC 3138 > > Class D address pool, and then set up ASM and SSM > > suballocations in that block (there are at least 1000 > /24's > > available for this, if needed). All other multicast > > addresses could then be filtered out if necessary in an > > emergency, and these filters could be set up in > advance. > > (There could be pools set up in this for European > > broadcasts, the USA, Japan, the UN, etc., etc.) > > > > This, of course, means that priority is a manual > > intervention scheme that would have to be triggered in > the > > NOC's or the equivalent, but a static, preconfigured, > > allocation scheme offers certain advantages in an > emergency, > > akin to "tune to channel 2 in case of an actual > emergency". > > > > Regards > > Marshall Eubanks > > > > > > > > -----Original Message----- > > > From: Marshall Eubanks [mailto:tme@multicasttech.com] > > > Sent: Friday, March 29, 2002 12:49 PM > > > To: Nguyen, An; 'Marshall Eubanks' > > > Cc: ieprep@ietf.org > > > Subject: Re: [Ieprep] Public Safety? > > > > > > > > > I would strongly urge (and am working on an I-D for) > the > > > use of multicast to distribute video in this > situation, > > > as > > > it scales well and avoids edge melt-downs. > > > See, e.g., my presentation to NANOG-23 > > > > > > http://www.nanog.org/mtg-0110/eubanks.html > > > > > > Regards > > > Marshall Eubanks > > > > > > > _______________________________________________ > > 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 From ieprep-admin@ietf.org Mon Apr 1 12:20:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06416 for ; Mon, 1 Apr 2002 12:20:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24260; Mon, 1 Apr 2002 12:20:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24229 for ; Mon, 1 Apr 2002 12:20:05 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06398 for ; Mon, 1 Apr 2002 12:20:02 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31HJXY21702; Mon, 1 Apr 2002 09:19:33 -0800 (PST) Message-Id: <5.1.0.14.2.20020401085508.01d59e68@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 08:55:10 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Folts' stated requirements: reliability constraints Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org In http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, you state that "A US Government working group recently identified fourteen basic functional requirements for the future ETS." Some of the issues you identify have already been discussed; most of these I think are obvious, though I have a couple to ask you about. Specifically, could ask ask you about these points that you made? +--------------------- ----------------------------------------- |d. Restorability Should a disruption occur, services must | be capable of being reprovisioned, | repaired, or restored to required service | levels on a priority basis. +--------------------- ----------------------------------------- |e. International Services must provide access to and |Connectivity egress from international carriers. +---------------------------------------------------------------- |f. Interoperability Services must interconnect and | interoperate with other selected | government or private facilities, | systems, and networks. +--------------------------------------------------------------- |h. Ubiquitous Coverage Services must be readily accessible to | support the national security leadership | and inter- and intra-agency emergency | operations, wherever they are located. +---------------------------------------------------------------- |i. Survivability/ Services must be robust to support | Endurability surviving users under a broad range of | circumstances, from the widespread damage | of a natural or man-made disaster up to | and including nuclear war. +---------------------------------------------------------------- |l. Scaleable Bandwidth NS/EP users must be able to manage the | capacity of the communications services | to support variable bandwidth | requirements. +---------------------------------------------------------------- |M. Affordability Services must leverage network | capabilities to minimize cost (e.g., use | of existing infrastructure, commercial | off-the-shelf technologies, services). +---------------------------------------------------------------- |n. Reliability/ Services must perform consistently and | Availability precisely according to their design | requirements and specifications, and must | be usable with high confidence. +---------------------------------------------------------------- It is my perception that the experiences of the Internet in Kobe in 1992, and in New York and Washington DC last fall, suggest that in fact these are characteristics of elastic applications running on the current Internet. Do you agree? If not, specifically what issues would you like to see addressed? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 12:22:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06495 for ; Mon, 1 Apr 2002 12:22:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24218; Mon, 1 Apr 2002 12:20:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24186 for ; Mon, 1 Apr 2002 12:20:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06392 for ; Mon, 1 Apr 2002 12:19:59 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31HJUY21674; Mon, 1 Apr 2002 09:19:30 -0800 (PST) Message-Id: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 08:30:00 -0800 To: ieprep@ietf.org From: Fred Baker Subject: Re: [Ieprep] a little homily Cc: ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020329172047.01d66930@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org We certainly need to be able to do our best, and any useful tool to counter a credible threat is a good thing to do. I am going to explain my reasoning with respect to multicast and a special multicast group of addresses. Please understand that I am all for multicast as a technology, and I am aware of other proposals on the table. These are examples, symptoms; I want to use them to address my underlying concern. Let me give you an insurance analogy. In Florida, one can insure one's home and property against a number of threats, including fire and hurricane damage. In California, where I live, one can insure one's home and property against a number of threats, including fire and earthquake damage. I don't know whether they sell earthquake insurance in Florida; I can tell you that they don't sell hurricane damage insurance for residences in California. The reason they don't sell it is because there is no credible threat - that's not a problem we have in California. Over the past week, we have had a presentation by someone who said he was writing a draft about multicast, and we have discussed the possible assignment of a set of class D addresses to emergency workers in case they can't get them during an emergency. In the Class D space, there are 2^24 (roughly 16 million) addresses, of which 2^20 (about one million) are specified as general multicast addresses routable by such protocols as PIM and DVMRP. In the past decade, it is unlikely that more than a hundred have been in use at any given time, because IP multicast is not heavily used in the commercial Internet, or anywhere else. Due to the low level of use, service providers do not routinely go to the effort to configure the capability - they don't see revenue in response to the effort. The evidence that there is a credible threat in the class D multicast address space is not in the least obvious. And by the way, the folks looking at IP Multicast during an emergency, according to all reports, are not emergency workers. Emergency workers could presumably use video teleconferencing for certain cases, but in a case where we're really happy to be making audio calls work, that's not the top of anyone's agenda that has commented to this working group. Emergency workers don't use IP multicast, or if they do they haven't bothered to report the fact. So these proposals come: - in the complete absence of utility in contemplated emergency communications - without any evidence of a credible threat - in a widespread absence of commercial deployment - when these points were questioned (by me), without even an attempt to justify them. However, if the proposal goes forward, what I hear is a requirement to assign addresses that will not be used to applications which do not exist, and a requirement for ~10,000 service providers world-wide to expend money on infrastructure for emergency communications which will not in fact be used. This is a waste of money, and an excellent argument for the people who read the recommendations of this working group to dismiss them out of hand, as silly and ill-considered. If you want the output of this working group to have an affect, any effect whatsoever, on what people do to support emergency telecommunications, the output has to be credible, and this is not. If you want the discussion to be relevant, I have two words for you: GGGG EEEEEE TTTTTTT RRRRRR EEEEEE A L GG GG E T RR RR E A A L GG EEE T RR RR EEE A A L GG GGG E T RRRRR E AAAAAAA L GG GG E T RR RR E A A L GGGG EEEEEE T RR RR EEEEEE A A LLLLLLL Now, we know that in an emergency, a fair bit of traffic can be generated, causing a massive and sudden congestive collapse. This can happen in three ways: - telephone switches (PSTN and IP) can be so overloaded that they are forced to ignore calls while they serve the ones they have - data application servers can be overloaded to such an extent that they are unable to support the load - data trunks can be overloaded in such a way that they drop a lot of traffic We can, realistically, look at the issues in these cases and ensure that they are covered. This requires a gap analysis and framework for emergency telephone switching; this is a chartered deliverable of this working group. It also requires a recommendation for the management of data traffic using elastic applications; this likewise is a chartered deliverable of this working group. If there are other credible threats, we need to surface them, and we need to make recommendations concerning them. Interesting solutions that meet no credible threat are out of scope. So any proposal of a solution to a problem needs to identify what threat it counters, and demonstrate that the threat is credible. Anything which does not do so is a waste of all of our time. I dunno, may you would spend money on Hurricane insurance in California. I wouldn't, and I don't want this working group expending time and energy on that class of threat. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 12:57:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07977 for ; Mon, 1 Apr 2002 12:57:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26982; Mon, 1 Apr 2002 12:56:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26947 for ; Mon, 1 Apr 2002 12:56:54 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07923 for ; Mon, 1 Apr 2002 12:56:51 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31HuGY18785; Mon, 1 Apr 2002 09:56:16 -0800 (PST) Message-Id: <5.1.0.14.2.20020401085850.01ea6260@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 09:30:42 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Folts' stated requirements: mobility Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org In http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, you state that "A US Government working group recently identified fourteen basic functional requirements for the future ETS." In section two, you mention +---------------------------------------------------------------- |g. Mobility The communications infrastructure must | support transportable, redeployable, or | fully mobile communications (e.g., | personal communications service, | cellular, satellite, high frequency | radio). +---------------------------------------------------------------- Is there a problem here that you are seeking to have addressed? It is my perception that Internet technology has strong mobility characteristics; the laptop has become essentially ubiquitous, PDA-based Instant Messaging and Email solutions exist and can be deployed, and we certainly do hear a lot about 3G. Are you looking for something different from or in addition to the capabilities that are currently available? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 13:39:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10119 for ; Mon, 1 Apr 2002 13:39:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02583; Mon, 1 Apr 2002 13:39:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02550 for ; Mon, 1 Apr 2002 13:39:07 -0500 (EST) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10061 for ; Mon, 1 Apr 2002 13:39:03 -0500 (EST) Received: from host213-1-165-12.btinternet.com ([213.1.165.12] helo=degree2.com) by tungsten.btinternet.com with esmtp (Exim 3.22 #8) id 16s6hq-0006Z3-00; Mon, 01 Apr 2002 19:39:03 +0100 Message-ID: <3CA8A96A.BED3870E@degree2.com> Date: Mon, 01 Apr 2002 19:39:38 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org Subject: Re: [Ieprep] Preemption References: <5849.1017437841@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ken, (and Stu also), > > I wonder if anyone on the operational side of PSTN, ISDN, GSM has any > > comment on the preemption issue? It would certainly help my > > understanding of practice. > > from my experience, the preemption that has been deployed is almost > exclusive to private networks, and I'll have to pass on comments. > > my understanding is that the UK, under the guidance of Oftel, has > deployed multiple priority indicators for their cellular/mobile > telephony service, but i don't believe preemption is part of that > service. i'll look into that. This is roughly in line with what I have heard. I believe that for GSM (in the UK, don't know about elsewhere) that there are multiple levels (15 possibly) that can be assigned and stored on the SIM. Engineering staff may occupy the top-levels, emergency about half way down (there may be multiple emergency priorities too), and the common herd (paying customers) lurk around in the nether regions. I also understand that there is no preemption for GSM in the UK. I can check further but Fred's comments reminded me that I may be drifting off-topic. If we can specify a priority and preemption scheme that works for the IP domain then the best we can do in this area should be consistent with the behaviour at the gateways. I wonder how we might test some of these things... Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:11:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11079 for ; Mon, 1 Apr 2002 14:11:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04515; Mon, 1 Apr 2002 14:08:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04468 for ; Mon, 1 Apr 2002 14:08:15 -0500 (EST) Received: from chntex01.is.dyncorp.com (chntex01.is.dyncorp.com [131.131.133.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11015 for ; Mon, 1 Apr 2002 14:08:09 -0500 (EST) Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 14:06:26 -0500 Message-ID: From: "Gunn, Janet NE" To: "'Alistair Munro'" , Ken Carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] Preemption Date: Mon, 1 Apr 2002 14:07:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D9B0.75657760" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D9B0.75657760 Content-Type: text/plain; charset="iso-8859-1" As I understand it, it is a bit more complicated than that. In order to establish a mobile call, first the handset must acquire a control channel. Once it has a control channel, it can request a traffic channel (voice or data if supported). WIthin GSM, eMLPP (extended MultiLevel Precedence and Pre-emption) has 7 levels. Of these, the two highest are reserved for network internal use, leaving 5 levels available for subsribers. These 5 levels affect the assignment of voice (and maybe data, I am not sure) traffic channels, and can be passed to the land-line PSTN as MLPP parameters. But if you can't get a control channel, you can't even request a traffic channel, and cannot be added to the queue. In a very high level sense, getting a control channel is analogous to getting dial tone in the landline PSTN. To address this, GSM has 15 levels of access class for control channel control. When the network operator detects congestion of the control channels, it can "turn off" all mobile sets with a given access class. These sets cannot even request a control channel until that access class is turned back on. Ordinary GSM mobile sets are typically "randommly" assigned to access classes 0 to 9. This is often just the last digit of the serial number. Under congestion, the network operator will typically deny one or more access classes in turn for a short time (say 5 and 8), then re-activate the them and deny another combination (say 3 and 7), and so on. This is (again on a high level) analogous to "call gapping" or other Network Management Controls in the landline PSTN. In order to exempt certain mobile handsets from this access control, they can be assigned to access classes 12, 13 or 14 (classes 11 and 15 are reserved for network internal use). Such special mobile sets would tpically have access class (say)13 IN ADDITION TO an access class 0 - 9. Note that there is no inherent "ordering" of the access classes. From a technical perspective the network operator could block access classes in any order or combination they chose. This is probably more than you wanted to know, but I wanted to explain where the 15 levels came from. Janet -----Original Message----- From: Alistair Munro [mailto:alistair.munro@degree2.com] Sent: Monday, April 01, 2002 1:40 PM To: Ken Carlberg Cc: ieprep@ietf.org Subject: Re: [Ieprep] Preemption Hi Ken, (and Stu also), > > I wonder if anyone on the operational side of PSTN, ISDN, GSM has any > > comment on the preemption issue? It would certainly help my > > understanding of practice. > > from my experience, the preemption that has been deployed is almost > exclusive to private networks, and I'll have to pass on comments. > > my understanding is that the UK, under the guidance of Oftel, has > deployed multiple priority indicators for their cellular/mobile > telephony service, but i don't believe preemption is part of that > service. i'll look into that. This is roughly in line with what I have heard. I believe that for GSM (in the UK, don't know about elsewhere) that there are multiple levels (15 possibly) that can be assigned and stored on the SIM. Engineering staff may occupy the top-levels, emergency about half way down (there may be multiple emergency priorities too), and the common herd (paying customers) lurk around in the nether regions. I also understand that there is no preemption for GSM in the UK. I can check further but Fred's comments reminded me that I may be drifting off-topic. If we can specify a priority and preemption scheme that works for the IP domain then the best we can do in this area should be consistent with the behaviour at the gateways. I wonder how we might test some of these things... Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep ------_=_NextPart_001_01C1D9B0.75657760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ieprep] Preemption

As I understand it, it is a bit more complicated than = that.

In order to establish a mobile call, first the = handset must acquire a control channel.  Once it has a control = channel, it can request a traffic channel (voice or data if = supported).

WIthin GSM, eMLPP (extended MultiLevel Precedence and = Pre-emption) has 7 levels.  Of these, the two highest are reserved = for network internal use, leaving 5 levels available for = subsribers.  These 5 levels affect the assignment of voice (and = maybe data, I am not sure) traffic channels, and can be passed to the = land-line PSTN as MLPP parameters.

But if you can't get a control channel, you can't = even request a traffic channel, and cannot be added to the queue.  = In a very high level sense, getting a control channel is analogous to = getting dial tone in the landline PSTN.

To address this, GSM has 15 levels of access class = for control channel control. When the network operator  detects = congestion of the control channels, it can "turn off" all = mobile sets with a given access class.  These sets cannot even = request a control channel until that access class is turned back = on.

Ordinary GSM mobile sets are typically = "randommly" assigned to access classes 0 to 9.  This is = often just the last digit of the serial number.  Under congestion, = the network operator will typically deny one or more access classes in = turn for a short time (say 5 and 8), then re-activate the them and deny = another combination (say 3 and 7), and so on.  This is (again on a = high level) analogous to "call gapping" or other Network = Management Controls in the landline PSTN.

In order to exempt certain mobile handsets from this = access control, they can be assigned to access classes 12, 13 or 14 = (classes 11 and 15 are reserved for network internal use).  Such = special mobile sets would tpically have access class (say)13 IN = ADDITION TO an access class 0 - 9.

Note that there is no inherent "ordering" = of the access classes.  From a technical perspective the network = operator could block  access classes in any order or combination = they chose.

This is probably more than you wanted to know, but I = wanted to explain where the 15 levels came from.

Janet

-----Original Message-----
From: Alistair Munro [mailto:alistair.munro@degree2= .com]
Sent: Monday, April 01, 2002 1:40 PM
To: Ken Carlberg
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] Preemption


Hi Ken, (and Stu also),

> > I wonder if anyone on the operational side = of PSTN, ISDN, GSM has any
> > comment on the preemption issue? It would = certainly help my
> > understanding of practice.
>
> from my experience, the preemption that has = been deployed is almost
> exclusive to private networks, and I'll have to = pass on comments.
>
> my understanding is that the UK, under the = guidance of Oftel, has
> deployed multiple priority indicators for their = cellular/mobile
> telephony service, but i don't believe = preemption is part of that
> service.  i'll look into that.

This is roughly in line with what I have heard. I = believe that for GSM (in
the UK, don't know about elsewhere) that there are = multiple levels (15
possibly) that can be assigned and stored on the = SIM. Engineering staff may
occupy the top-levels, emergency about half way down = (there may be multiple
emergency priorities too), and the common herd = (paying customers) lurk
around in the nether regions.

I also understand that there is no preemption for GSM = in the UK. I can
check further but Fred's comments reminded me that I = may be drifting
off-topic. If we can specify a priority and = preemption scheme that works
for the IP domain then the best we can do in this = area should be consistent
with the behaviour at the gateways.

I wonder how we might test some of these = things...

Regards,

Alistair



_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

------_=_NextPart_001_01C1D9B0.75657760-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:15:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11136 for ; Mon, 1 Apr 2002 14:15:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04853; Mon, 1 Apr 2002 14:15:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04821 for ; Mon, 1 Apr 2002 14:15:01 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11132 for ; Mon, 1 Apr 2002 14:14:57 -0500 (EST) Received: from host213-1-165-12.btinternet.com ([213.1.165.12] helo=degree2.com) by gadolinium.btinternet.com with esmtp (Exim 3.22 #8) id 16s7GY-0000om-00; Mon, 01 Apr 2002 20:14:54 +0100 Message-ID: <3CA8B1D1.8691306B@degree2.com> Date: Mon, 01 Apr 2002 20:15:29 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org Subject: Re: [Ieprep] a little homily References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > We can, realistically, look at the issues in these cases and ensure that > they are covered. This requires a gap analysis and framework for emergency > telephone switching; this is a chartered deliverable of this working group. > It also requires a recommendation for the management of data traffic using > elastic applications; this likewise is a chartered deliverable of this > working group. Your comment about the similarity between the requirements of elastic applications and the availability requirements for emergency traffic (Folt's stated requirements..) plus other comments under the "public safety" confirms (if there were any doubt) that an IP platform should work better than a circuit mode platform in being able to *place* a vary large number of calls in a very highly congested situation. However once the call is placed it will generate voice (elastic/non-elastic - it depends...) and associated data traffic (elastic, IM, whatever) which must be differentiated for the session end-to-end, where the ends may be inside/outside the emergency area, in call-centres, at personal or public phones, Blackberries, etc., etc. I had been looking at the availability issues for emergency services before this WG got flowing and was not sure whether the existing IP QoS models were suitable to support this dense differentiation under the likely traffic load. I do not think packet marking would be enough to secure the traffic. Id there a specific proposal yet - I could tell from recent and historical discussion in this group and related ones? Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:25:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11269 for ; Mon, 1 Apr 2002 14:25:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05236; Mon, 1 Apr 2002 14:24:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05199 for ; Mon, 1 Apr 2002 14:24:15 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11260 for ; Mon, 1 Apr 2002 14:24:04 -0500 (EST) Received: from [63.105.122.247] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1331100; Mon, 01 Apr 2002 14:23:50 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] Public Safety? To: Fred Baker , "Marshall Eubanks" Cc: ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 01 Apr 2002 14:23:50 -0500 Message-ID: In-Reply-To: <5.1.0.14.2.20020329155930.0247fde0@mira-sjcm-4.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Fri, 29 Mar 2002 16:06:21 -0800 Fred Baker wrote: > At 03:28 PM 3/29/2002, Marshall Eubanks wrote: > >1.) There are _six_ different formats with some market > >share. > > > >2.) Little wars break out to deny or gain > interoperability, > > Understood. That is the subject of > http://www.ietf.org/html.charters/impp-charter.html, > where the little wars > happen in a teakettle, which in turns whistles > continuously. It's quite > noisy, as you may guess. > > The question before *this* house is whether there is > something specific > that is required for IM to be useful to emergency workers > - a specific > configuration, a specific diffserv service specified on > the packets (and > please demonstrate that there is a problem that this > solves), or whatever. > I'm right with you in voting for interoperability. That's > not the issue > before this working group, except to add one set of votes > for the actors in > the IM drama to stop their silly > lets-be-anything-but-interoperable games. > My guess is that this is an unsolveable problem for political reasons, as the most interoperable solution would be "use AIM", which my guess is not politically acceptable. Regards Marshall Eubanks _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:28:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11327 for ; Mon, 1 Apr 2002 14:28:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05416; Mon, 1 Apr 2002 14:27:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05358 for ; Mon, 1 Apr 2002 14:27:43 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11319 for ; Mon, 1 Apr 2002 14:27:39 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31JR5Y05938; Mon, 1 Apr 2002 11:27:05 -0800 (PST) Message-Id: <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 11:23:01 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] a little homily Cc: ieprep@ietf.org In-Reply-To: <3CA8B1D1.8691306B@degree2.com> References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:15 AM 4/1/2002, Alistair Munro wrote: >I had been looking at the availability issues for emergency services >before this WG >got flowing and was not sure whether the existing IP QoS models were >suitable to >support this dense differentiation under the likely traffic load. I do not >think >packet marking would be enough to secure the traffic. QoS is not an authentication or encryption technology; IP QoS is not designed to "secure" anything. By this, do you mean that IP QoS is not able to ensure that each individual session is able to be guaranteed a specific throughput? What specifically do you mean? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:37:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11590 for ; Mon, 1 Apr 2002 14:37:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06328; Mon, 1 Apr 2002 14:35:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06290 for ; Mon, 1 Apr 2002 14:35:42 -0500 (EST) Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11559 for ; Mon, 1 Apr 2002 14:35:38 -0500 (EST) Received: from host213-1-165-12.btinternet.com ([213.1.165.12] helo=degree2.com) by protactinium with esmtp (Exim 3.22 #8) id 16s7aX-0004Xs-00; Mon, 01 Apr 2002 20:35:33 +0100 Message-ID: <3CA8B6A8.B171AA42@degree2.com> Date: Mon, 01 Apr 2002 20:36:09 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn, Janet NE" CC: Ken Carlberg , ieprep@ietf.org Subject: Re: [Ieprep] Preemption References: Content-Type: multipart/alternative; boundary="------------2AF4072BA3BFCC1B0CD31F82" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --------------2AF4072BA3BFCC1B0CD31F82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Janet, > As I understand it, it is a bit more complicated than that. > .... > This is probably more than you wanted to know, but I wanted to explain > where the 15 levels came from. Aargh, thanks for the corrections and clarifications :-). Sorry if I caused some confusion - I was not thinking about the issue of getting the control channel but about what happened from the first switch inwards. I imagine that all the access class issues can be mapped somehow into the SIP domain, and that the issues of prioritising/preempting calls would be similar whether we were using a SIP switch or a PSTN one. For GSM systems (or TETRA, or many of the other digital cellular systems around), as far acquiring the control channel is concerned, is this orthogonal to the treatment of the call subsequently? It is a competitive process on a shared medium (layer 2) up to a point, which I believe is a sub-IP issue that could be raised in a similar way for an 802.11 network with 802.1d/1p/1q, but, once established its progress is certain - which would not apply to an IP platform. Would an IP platform perform any better or worse than a GSM one? I think yes, if only because a TDM system will run out of slots. What about GPRS? Regards, Alistair --------------2AF4072BA3BFCC1B0CD31F82 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Janet,
As I understand it, it is a bit more complicated than that.
....
This is probably more than you wanted to know, but I wanted to explain where the 15 levels came from.
Aargh, thanks for the corrections and clarifications :-).

Sorry if I caused some confusion - I was not thinking about the issue of getting the control channel but about what happened from the first switch inwards. I imagine that all the access class issues can be mapped somehow into the SIP domain, and that the issues of prioritising/preempting calls would be similar whether we were using a SIP switch or a PSTN one.

For GSM systems (or TETRA, or many of the other digital cellular systems around), as far acquiring the control channel is concerned, is this orthogonal to the treatment of the call subsequently?  It is a competitive process on a shared medium (layer 2) up to a point, which I believe is a sub-IP issue that could be raised in a similar way for an 802.11 network with 802.1d/1p/1q, but, once established its progress is certain - which would not apply to an IP platform. Would an IP platform perform any better or worse than a GSM one? I think yes, if only because a TDM system will run out of slots. What about GPRS?

Regards,

Alistair --------------2AF4072BA3BFCC1B0CD31F82-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:38:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11621 for ; Mon, 1 Apr 2002 14:38:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06449; Mon, 1 Apr 2002 14:38:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06403 for ; Mon, 1 Apr 2002 14:38:18 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11609 for ; Mon, 1 Apr 2002 14:38:13 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31JbjY14138; Mon, 1 Apr 2002 11:37:45 -0800 (PST) Message-Id: <5.1.0.14.2.20020401112735.01d5b008@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 11:37:26 -0800 To: "Marshall Eubanks" From: Fred Baker Subject: Re: [Ieprep] Public Safety? Cc: ieprep@ietf.org In-Reply-To: References: <5.1.0.14.2.20020329155930.0247fde0@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:23 AM 4/1/2002, Marshall Eubanks wrote: >My guess is that this is an unsolveable problem for political reasons, as >the most interoperable solution would be "use AIM", which my guess is not >politically acceptable. It's not a matter of politics, it's a matter of what a standards body does. If the right answer in the US is "use AIM", then maybe the thing for the US Government to do is mandate that to all US agencies - that would be its choice. I'm fairly certain that "use AIM" is *not* the right answer in the People's Republic of China, which also uses IETF specifications, and it might not be the right answer for a global organization like the US Military. The IETF is a body of engineers that design protocols, and whose protocols are used throughout the world. The IETF doesn't pick companies and recommend them. So for us, it's not a matter of the political acceptability or unacceptability of that particular service; we simply don't do that. It would be good, though, if the IETF could design a single instant messaging standard and have all the services use that. The fact is, as Henning pointed out, that IMM attempted to do just that, and was thwarted by various services that fundamentally didn't want to be interoperable - they see what you describe as a "problem" as a "business opportunity". IMM ultimately got separated into three separate working groups, two of which appear to be moribund (the operators in question decided that their interests were not served by being "among the winners" unless they can also slow down the other "co-winners", so they have chosen to not work on it), and the third of which (which has been delayed by the jockeying in IMM) may or may not ultimately find itself being used by the operators - we'll see. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 14:39:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11636 for ; Mon, 1 Apr 2002 14:39:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06498; Mon, 1 Apr 2002 14:38:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06461 for ; Mon, 1 Apr 2002 14:38:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11615 for ; Mon, 1 Apr 2002 14:38:18 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31JbiY14134; Mon, 1 Apr 2002 11:37:45 -0800 (PST) Message-Id: <5.1.0.14.2.20020401112414.01ec2110@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 11:27:00 -0800 To: "Gunn, Janet NE" From: Fred Baker Subject: RE: [Ieprep] Preemption Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:07 AM 4/1/2002, Gunn, Janet NE wrote: >Note that there is no inherent "ordering" of the access classes. From a >technical perspective the network operator could block access classes in >any order or combination they chose. so the access classes are in fact labels ("this is traffic of this class"), and the network provider can apply any policy he likes ("class is normal users and might get crowded out, but class has a limited pool of users and unlimited authority to use available bandwidth"). I believe that this is largely what Ken is proposing in his framework draft, and similar to what is being proposed in SIP/SIPPING. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:07:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12429 for ; Mon, 1 Apr 2002 15:07:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08105; Mon, 1 Apr 2002 15:07:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08068 for ; Mon, 1 Apr 2002 15:07:21 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12418 for ; Mon, 1 Apr 2002 15:07:13 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Apr 2002 21:07:15 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Apr 2002 21:07:13 +0100 Message-ID: <1565.1017691633@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] multicast Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org so, at the risk of giving Fred some indigestion, i'll put forth these thoughts about multicast and emergency services. push-to-talk is an existing capability in public safety wireless networks (PSWN) that would be complimented/supported quite well with multicast in cases where one wants to migrate push-to-talk into the IP world. having said that, multicast in this case is predominantly within a single subnet. this can be expected to possibly span to a 'few' other stub subnets if we assume a model where police,fire, ambulance have their own IP subnets and yet need to communicate with each other. (note: this cross-agency requirement exists today and goverment agencies of the US have procurements to achieve this in the very near future in the telco/PSWN world). with the above scenario, and keeping in mind Fred's previous comment about multicast (and the use of SSM and IGMPv3), i don't see big stumbling blocks in supporting multicast. and i'm not thrilled about statically reserving class D address blocks. as an example, one can go back to RFC1700 to see class D block assignments that never saw light of day. also, if one were to consider associating an emergency with a specific class D address, i would expect to see some specific comments about MALLOC's role in this. the only arguement that I can think of for having a Class D address be attributed for emergency, is to allow it to bypass management controls such as rate limiting, which is what we used for the old Mbone. the downside to this, though, is that this may contribute to increasing the short term problem of congestion (ie, i'm shooting myself in the foot). the only other thought that i can dream up is getting past middleware boxes (for example firewalls) that by default stop all mcast traffic from getting through. but at this point i'm reaching in the role of devil's advocate. so, perhaps we can put this thread to rest until someone puts forth an I-D that has some specifics, and addresses the issues/concerns stated so far. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:11:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12510 for ; Mon, 1 Apr 2002 15:11:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08290; Mon, 1 Apr 2002 15:10:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08258 for ; Mon, 1 Apr 2002 15:10:23 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12463 for ; Mon, 1 Apr 2002 15:10:19 -0500 (EST) Received: from host213-122-82-121.in-addr.btopenworld.com ([213.122.82.121] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16s88A-0005ce-00; Mon, 01 Apr 2002 21:10:19 +0100 Message-ID: <3CA8BECD.45008F90@degree2.com> Date: Mon, 01 Apr 2002 21:10:54 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] IP QoS and availability (split off from ... a little homily ...) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, Sorry if this comes through twice in slightly different versions. My server connection got blasted and I couldn't tell which bit failed. > QoS is not an authentication or encryption technology; ???? Did I mention security ???? > IP QoS is not > designed to "secure" anything. I should have said "secure the traffic", by which I mean "ensure its delivery according to the QoS requested". > By this, do you mean that IP QoS is not able to ensure that each individual > session is able to be guaranteed a specific throughput? What specifically > do you mean? I was wondering (a) when a guarantee of throughput was appropriate, (and to what would it be given), and (b) how one would use the IP QoS model to differentiate traffic for a very large number of flows and a high local aggregate traffic intensity (which seemed to be a close model to an emergency situation). It was a question, not an assertion - I cannot see how. I am trying to get away from the preemption discussion, which seems to be soluble, and look at how to keep the traffic flowing while it is being battered by all the other stuff. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:13:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12541 for ; Mon, 1 Apr 2002 15:13:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08215; Mon, 1 Apr 2002 15:08:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08174 for ; Mon, 1 Apr 2002 15:08:35 -0500 (EST) Received: from chntex01.is.dyncorp.com (chntex01.is.dyncorp.com [131.131.133.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12449 for ; Mon, 1 Apr 2002 15:08:29 -0500 (EST) Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 15:06:55 -0500 Message-ID: From: "Gunn, Janet NE" To: "'Fred Baker'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] Preemption Date: Mon, 1 Apr 2002 15:07:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D9B8.E8991180" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D9B8.E8991180 Content-Type: text/plain; charset="iso-8859-1" Yes, access classes are labels. There is, howeveer, an implicit assumption that levels 0 though 9 will, on average, receive "equivalent" treatment, and only levels 11-15 will receive "different" treatment. ALso, the access class is a property of the HANDSET, and applies to all call attempts form that handset. The eMLPP priority levels can be invoked on a call-by-call basis. -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Monday, April 01, 2002 2:27 PM To: Gunn, Janet NE Cc: ieprep@ietf.org Subject: RE: [Ieprep] Preemption At 11:07 AM 4/1/2002, Gunn, Janet NE wrote: >Note that there is no inherent "ordering" of the access classes. From a >technical perspective the network operator could block access classes in >any order or combination they chose. so the access classes are in fact labels ("this is traffic of this class"), and the network provider can apply any policy he likes ("class is normal users and might get crowded out, but class has a limited pool of users and unlimited authority to use available bandwidth"). I believe that this is largely what Ken is proposing in his framework draft, and similar to what is being proposed in SIP/SIPPING. ------_=_NextPart_001_01C1D9B8.E8991180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ieprep] Preemption

Yes, access classes are labels.  There is, = howeveer, an implicit assumption that levels 0 though 9 will, on = average, receive "equivalent" treatment, and only levels = 11-15 will receive "different" treatment.

ALso, the access class is a property of the HANDSET, = and applies to all call attempts form that handset.  The eMLPP = priority levels can be invoked on a call-by-call basis.

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Monday, April 01, 2002 2:27 PM
To: Gunn, Janet NE
Cc: ieprep@ietf.org
Subject: RE: [Ieprep] Preemption


At 11:07 AM 4/1/2002, Gunn, Janet NE wrote:
>Note that there is no inherent = "ordering" of the access classes.  From a
>technical perspective the network operator could = block  access classes in
>any order or combination they chose.

so the access classes are in fact labels ("this = is traffic of this class"),
and the network provider can apply any policy he = likes ("class <this> is
normal users and might get crowded out, but class = <that> has a limited pool
of users and unlimited authority to use available = bandwidth").

I believe that this is largely what Ken is proposing = in his framework
draft, and similar to what is being proposed in = SIP/SIPPING.

------_=_NextPart_001_01C1D9B8.E8991180-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:22:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12832 for ; Mon, 1 Apr 2002 15:22:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08664; Mon, 1 Apr 2002 15:19:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08630 for ; Mon, 1 Apr 2002 15:19:38 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12740 for ; Mon, 1 Apr 2002 15:19:33 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA15918; Mon, 1 Apr 2002 12:18:16 -0800 (PST) Message-Id: <4.1.20020401141502.031c1bd8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 01 Apr 2002 14:17:47 -0600 To: Sean Donelan , "Nguyen, An" From: "James M. Polk" Subject: RE: [Ieprep] multicast Cc: "'Marshall Eubanks'" , "Gunn, Janet NE" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_834392723==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_834392723==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:34 PM 3/29/2002 -0500, Sean Donelan wrote: > > >On Fri, 29 Mar 2002, Nguyen, An wrote: > >Government directed pre-emption isn't always the best way to handle an >emergency. But... there are times when it is best, like during a tornado touchdown in a known area. People have the habit of tuning-out the news at really inconvenient times, making sure all channels are delivering the message is a good thing. > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_834392723==_.ALT Content-Type: text/html; charset="us-ascii"
At 02:34 PM 3/29/2002 -0500, Sean Donelan wrote:
>
>
>On Fri, 29 Mar 2002, Nguyen, An wrote:
<snip>
>
>Government directed pre-emption isn't always the best way to handle an
>emergency.

But... there are times when it is best, like during a tornado touchdown in a known area. People have the habit of tuning-out the news at really inconvenient times, making sure all channels are delivering the message is a good thing.


>
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_834392723==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:29:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13590 for ; Mon, 1 Apr 2002 15:29:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09038; Mon, 1 Apr 2002 15:29:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09006 for ; Mon, 1 Apr 2002 15:29:05 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13448 for ; Mon, 1 Apr 2002 15:29:00 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA29453; Mon, 1 Apr 2002 12:28:31 -0800 (PST) Message-Id: <4.1.20020401142133.0c510d70@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 01 Apr 2002 14:28:01 -0600 To: "Marshall Eubanks" , "Nguyen, An" , "'Marshall Eubanks'" , "Nguyen, An" From: "James M. Polk" Subject: Re: [Ieprep] Public Safety? Cc: ieprep@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_835006996==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_835006996==_.ALT Content-Type: text/plain; charset="us-ascii" At 05:39 PM 3/29/2002 -0500, Marshall Eubanks wrote: >On Fri, 29 Mar 2002 13:40:25 -0500 > >So, I cannot see a situation where multicast is >intrinsically worse than unicast, and would interested in >learning of such. Both techniques are subject to a variety >of attacks, but I do not see any intrinsic DOS superiority >either way. So how do you create effective Security Associations between hosts using Multicast? That image of the devastation at ground zero that a higher ranking emergency official wanted to see *well* before it could become public would have gone public over an uncontrollable multicast stream. That image could have been someone really hurt bad and getting visual advice from a Doctor to a paramedic on how to treat that particular wound type.... or the structural views of a supporting wall or pillar that had people trapped below. If we're going to include Video, we should look at what that video could show in its delivery before trying to solve that problem, IMO ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_835006996==_.ALT Content-Type: text/html; charset="us-ascii"
At 05:39 PM 3/29/2002 -0500, Marshall Eubanks wrote:
>On Fri, 29 Mar 2002 13:40:25 -0500
<snip>
>
>So, I cannot see a situation where multicast is
>intrinsically worse than unicast, and would interested in
>learning of such. Both techniques are subject to a variety
>of attacks, but I do not see any intrinsic DOS superiority
>either way.

So how do you create effective Security Associations between hosts using Multicast?

That image of the devastation at ground zero that a higher ranking emergency official wanted to see *well* before it could become public would have gone public over an uncontrollable multicast stream.

That image could have been someone really hurt bad and getting visual advice from a Doctor to a paramedic on how to treat that particular wound type.... or the structural views of a supporting wall or pillar that had people trapped below.

If we're going to include Video, we should look at what that video could show in its delivery before trying to solve that problem, IMO


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_835006996==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:36:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13853 for ; Mon, 1 Apr 2002 15:36:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09910; Mon, 1 Apr 2002 15:35:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09880 for ; Mon, 1 Apr 2002 15:35:48 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13837 for ; Mon, 1 Apr 2002 15:35:43 -0500 (EST) Received: from host213-122-116-26.in-addr.btopenworld.com ([213.122.116.26] helo=degree2.com) by gadolinium.btinternet.com with esmtp (Exim 3.22 #8) id 16s8Wj-0000Zh-00; Mon, 01 Apr 2002 21:35:42 +0100 Message-ID: <3CA8C4C0.B0947BD9@degree2.com> Date: Mon, 01 Apr 2002 21:36:16 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: "Folts, Harold" , ieprep@ietf.org Subject: Re: [Ieprep] Folts' stated requirements: mobility References: <5.1.0.14.2.20020401085850.01ea6260@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > In > http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, > [Folt] state[s] that "A US Government working group recently identified > fourteen > basic functional requirements for the future ETS." > > In section two, you mention > +---------------------------------------------------------------- > |g. Mobility The communications infrastructure must > | support transportable, redeployable, or > | fully mobile communications (e.g., > | personal communications service, > | cellular, satellite, high frequency > | radio). > +---------------------------------------------------------------- > > Is there a problem here that you are seeking to have addressed? It is my > perception that Internet technology has strong mobility characteristics; > the laptop has become essentially ubiquitous, PDA-based Instant Messaging > and Email solutions exist and can be deployed, and we certainly do hear a > lot about 3G. Are you looking for something different from or in addition > to the capabilities that are currently available? As far as requirement (g) is concerned, if IP is supported in these infrastructures and supported properly, including QoS, handoff between them, then it can be used. There are IP portability solutions that work if you don't care about having a permanent IP address and other persistent services - DHCP, etc. will provide. They work if you do care about having a permanent IP address - you can use mobile IP if your providers and home network support it. My perception of a problem in this area is one of performance, not technology or protocols. What will we recommend as the best thing to do? Note: Janet mentioned the E911 directive on location/positioning availability. Do we have to make recommendations on this and its performance, - which will vary according to the underlying technology and terminal capabilities? Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 15:46:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14142 for ; Mon, 1 Apr 2002 15:46:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10232; Mon, 1 Apr 2002 15:42:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10199 for ; Mon, 1 Apr 2002 15:42:19 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13983 for ; Mon, 1 Apr 2002 15:42:16 -0500 (EST) Received: from [63.105.122.236] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1331144; Mon, 01 Apr 2002 15:42:17 -0500 Message-ID: <3CA8C629.9090101@multicasttech.com> Date: Mon, 01 Apr 2002 15:42:17 -0500 From: Marshall Eubanks User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "James M. Polk" CC: "Nguyen, An" , ieprep@ietf.org Subject: Re: [Ieprep] Public Safety? References: <4.1.20020401142133.0c510d70@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit TESLA http://www.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt Regards Marshall James M. Polk wrote: > At 05:39 PM 3/29/2002 -0500, Marshall Eubanks wrote: > > >On Fri, 29 Mar 2002 13:40:25 -0500 > > > > > > > >So, I cannot see a situation where multicast is > > >intrinsically worse than unicast, and would interested in > > >learning of such. Both techniques are subject to a variety > > >of attacks, but I do not see any intrinsic DOS superiority > > >either way. > > > So how do you create effective Security Associations between hosts using > Multicast? > > > That image of the devastation at ground zero that a higher ranking > emergency official wanted to see *well* before it could become public > would have gone public over an uncontrollable multicast stream. > > > That image could have been someone really hurt bad and getting visual > advice from a Doctor to a paramedic on how to treat that particular > wound type.... or the structural views of a supporting wall or pillar > that had people trapped below. > > > If we're going to include Video, we should look at what that video could > show in its delivery before trying to solve that problem, IMO > > > > ************************************* > "People generally demand more respect for their own rights than they are > willing to allow for others" > > James M. Polk > Consulting Engineer > Office of the CTO > > Cisco Systems > 2200 East President George Bush Turnpike > Richardson, TX 75082 USA > w) 972.813.5208 > f) 972.813.5280 > www.cisco.com -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 16:00:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14673 for ; Mon, 1 Apr 2002 16:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10912; Mon, 1 Apr 2002 15:59:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10852 for ; Mon, 1 Apr 2002 15:59:24 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14567 for ; Mon, 1 Apr 2002 15:59:21 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA04703; Mon, 1 Apr 2002 12:58:36 -0800 (PST) Message-Id: <4.1.20020401145718.0c170e70@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 01 Apr 2002 14:58:07 -0600 To: "Gunn, Janet NE" , "'Alistair Munro'" , Ken Carlberg From: "James M. Polk" Subject: RE: [Ieprep] Preemption Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_836812372==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_836812372==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:07 PM 4/1/2002 -0500, Gunn, Janet NE wrote: > > As I understand it, it is a bit more complicated than that. > > In order to establish a mobile call, first the handset must acquire a control > channel. Once it has a control channel, it can request a traffic channel > (voice or data if supported). > > WIthin GSM, eMLPP (extended MultiLevel Precedence and Pre-emption) has 7 > levels. Of these, the two highest are reserved for network internal use, > leaving 5 levels available for subsribers. These 5 levels affect the > assignment of voice (and maybe data, I am not sure) traffic channels, and can > be passed to the land-line PSTN as MLPP parameters. > > But if you can't get a control channel, you can't even request a traffic > channel, and cannot be added to the queue. In a very high level sense, > getting a control channel is analogous to getting dial tone in the landline > PSTN. > > To address this, GSM has 15 levels of access class for control channel > control. When the network operator detects congestion of the control > channels, it can "turn off" all mobile sets with a given access class. These > sets cannot even request a control channel until that access class is turned > back on. > > Ordinary GSM mobile sets are typically "randommly" assigned to access classes > 0 to 9. This is often just the last digit of the serial number. Under > congestion, the network operator will typically deny one or more access > classes in turn for a short time (say 5 and 8), then re-activate the them and > deny another combination (say 3 and 7), and so on. This is (again on a high > level) analogous to "call gapping" or other Network Management Controls in > the landline PSTN. > > In order to exempt certain mobile handsets from this access control, they can > be assigned to access classes 12, 13 or 14 (classes 11 and 15 are reserved > for network internal use). Such special mobile sets would tpically have > access class (say)13 IN ADDITION TO an access class 0 - 9. > > Note that there is no inherent "ordering" of the access classes. From a > technical perspective the network operator could block access classes in any > order or combination they chose. > > This is probably more than you wanted to know, but I wanted to explain where > the 15 levels came from. I liked the education > > Janet > > -----Original Message----- ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_836812372==_.ALT Content-Type: text/html; charset="us-ascii" At 02:07 PM 4/1/2002 -0500, Gunn, Janet NE wrote:

As I understand it, it is a bit more complicated than that.

In order to establish a mobile call, first the handset must acquire a control channel.  Once it has a control channel, it can request a traffic channel (voice or data if supported).

WIthin GSM, eMLPP (extended MultiLevel Precedence and Pre-emption) has 7 levels.  Of these, the two highest are reserved for network internal use, leaving 5 levels available for subsribers.  These 5 levels affect the assignment of voice (and maybe data, I am not sure) traffic channels, and can be passed to the land-line PSTN as MLPP parameters.

But if you can't get a control channel, you can't even request a traffic channel, and cannot be added to the queue.  In a very high level sense, getting a control channel is analogous to getting dial tone in the landline PSTN.

To address this, GSM has 15 levels of access class for control channel control. When the network operator  detects congestion of the control channels, it can "turn off" all mobile sets with a given access class.  These sets cannot even request a control channel until that access class is turned back on.

Ordinary GSM mobile sets are typically "randommly" assigned to access classes 0 to 9.  This is often just the last digit of the serial number.  Under congestion, the network operator will typically deny one or more access classes in turn for a short time (say 5 and 8), then re-activate the them and deny another combination (say 3 and 7), and so on.  This is (again on a high level) analogous to "call gapping" or other Network Management Controls in the landline PSTN.

In order to exempt certain mobile handsets from this access control, they can be assigned to access classes 12, 13 or 14 (classes 11 and 15 are reserved for network internal use).  Such special mobile sets would tpically have access class (say)13 IN ADDITION TO an access class 0 - 9.

Note that there is no inherent "ordering" of the access classes.  From a technical perspective the network operator could block  access classes in any order or combination they chose.

This is probably more than you wanted to know, but I wanted to explain where the 15 levels came from.

I liked the education


Janet

-----Original Message-----

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_836812372==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 16:31:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15745 for ; Mon, 1 Apr 2002 16:31:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13288; Mon, 1 Apr 2002 16:30:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13247 for ; Mon, 1 Apr 2002 16:30:47 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15720 for ; Mon, 1 Apr 2002 16:30:39 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31LU5Y08852; Mon, 1 Apr 2002 13:30:05 -0800 (PST) Message-Id: <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 13:30:00 -0800 To: Alistair Munro From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: <3CA8B9C1.19799800@degree2.com> References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] fine-grain QoS Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:49 AM 4/1/2002, Alistair Munro wrote: > From what I know of IP QoS, there are mechanisms to guarantee throughput > for aggregates and flows. How would they be applied effectively for fine > grain differentiation (large number of flows) under very high traffic > intensities? You might read RFC 3246. Fine grain QoS is a non-goal in IP. If you trace the signal flow in H.323, the process of setting up a call requires something on the order of 50 messages, and that is apart from the additional RSVP overhead of ensuring that the call has bandwidth. That makes sense if you are setting up shared state which is going to have a lifetime of several minutes and will affect O(50) datagrams per second while it is set up. It turns out, however, that for Voice or Video on IP, one has to ensure that there is sufficient bandwidth for the call, and one has to ensure that no call stream over-uses its comitment. Once you have done that, you have ensured that each individual flow also has the characteristics it needs, and further QoS negotiation is unnecessary - just please mark it so that we can police it properly and put it into the right queue. But for elastic traffic, which represents O(95%) of Internet traffic, it doesn't make sense. The median TCP session has <= 10 packets going each way, and no concept of a rate, as there is only one actual data segment each way. To try to set up call state as it exists in the telco world, and make "per-call" guarantees, is to dramatically increase the message traffic without materially changing much, and even to set up RSVP flow state for such sessions is difficult as there is no concept of a rate - and the guy requesting the rate has no concept of the amount of data he is asking for. So we actively avoided the question for elastic traffic, and in the case of inelastic voice/video traffic, enable you to negotiate the bandwidth using RSVP. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 16:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15758 for ; Mon, 1 Apr 2002 16:31:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13115; Mon, 1 Apr 2002 16:30:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13076 for ; Mon, 1 Apr 2002 16:30:28 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15715 for ; Mon, 1 Apr 2002 16:30:25 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g31LToY08642; Mon, 1 Apr 2002 13:29:50 -0800 (PST) Message-Id: <5.1.0.14.2.20020401131858.022f58d0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 13:22:42 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] Folts' stated requirements: mobility Cc: ieprep@ietf.org In-Reply-To: <3CA8C4C0.B0947BD9@degree2.com> References: <5.1.0.14.2.20020401085850.01ea6260@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:36 PM 4/1/2002, Alistair Munro wrote: >Do we have to make recommendations on this and its performance, - which will >vary according to the underlying technology and terminal capabilities? you tell me? I don't believe we have to make recommendations concerning the performance of anything, as the IETF has not historically designed services per se - those are the result of contracts with service providers, and would be specified in RFPs or RFIs for those services. "You want service like , you pay <$$>, You want twice that level of service, you pay <$$$$>". The IETF specifies protocols that enable people to build services; it is not a one-stop shopping place that the service providers listen to in what services they offer. We have, however, been asked to make recommendations about how those RFIs/RFPs might be structured, and how people might deploy or use the resulting service. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 19:27:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20158 for ; Mon, 1 Apr 2002 19:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22150; Mon, 1 Apr 2002 19:22:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22120 for ; Mon, 1 Apr 2002 19:22:54 -0500 (EST) Received: from sven.kdmd.net (adsl-64-160-215-222.dsl.frsn01.pacbell.net [64.160.215.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20112 for ; Mon, 1 Apr 2002 19:22:50 -0500 (EST) Received: from GW-KDMD-Message_Server by sven.kdmd.net with Novell_GroupWise; Mon, 01 Apr 2002 16:22:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 01 Apr 2002 16:22:34 -0600 From: "Ken Diliberto" To: Subject: Re: [Ieprep] Public Safety - Instant Messaging Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA22121 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit My idea of the ideal IM software is from Yahoo. I'm not saying we should adopt it, I just like the features: Text, voice and video. I'm thinking about a police officer/fire fighter with a suitable IM device walking through a disaster area having the ability to send pictures back to a command center. I know Fresno has a mobile command vehicle run by the SWAT team. There is a "room" in the back for politicians to make their decisions based on the available information. In many cases, a news camera might be a better solution but I know there are times the police don't want the news to have access initially. My example (in my mind) is for a handheld device using something like 802.11a/b talking to a mobile command center. This could also be via the Internet directly using the cellular network if available. Being a Ham Radio Operator, I don't keep much faith in cellular in an emergency (I guess that's the nature of Hams). I think whatever IM solution is specified, it should operate in a point-to-point method as a backup to a server based method. The problem I am trying to solve is getting the decision makers the information they need as soon as possible so the best decisions can be made. Having a mix of Inter/IntraNet technology make sense to me. I see this as an interagency solution as well. Ken >>> Fred Baker 04/01/02 01:37PM >>> At 11:23 AM 4/1/2002, Marshall Eubanks wrote: >My guess is that this is an unsolveable problem for political reasons, as >the most interoperable solution would be "use AIM", which my guess is not >politically acceptable. It's not a matter of politics, it's a matter of what a standards body does. [snip] _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 19:41:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20461 for ; Mon, 1 Apr 2002 19:41:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23154; Mon, 1 Apr 2002 19:40:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23120 for ; Mon, 1 Apr 2002 19:40:35 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20429 for ; Mon, 1 Apr 2002 19:40:32 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g320e1Y23575; Mon, 1 Apr 2002 16:40:01 -0800 (PST) Received: from SKEAGY-W2K1.cisco.com (dhcp-171-69-95-88.cisco.com [171.69.95.88]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA16895; Mon, 1 Apr 2002 16:39:51 -0800 (PST) Message-Id: <4.3.2.7.2.20020401160211.0598d550@malone.cisco.com> X-Sender: skeagy@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Apr 2002 16:39:51 -0800 To: Fred Baker , Alistair Munro From: Scott Keagy Subject: Re: [Ieprep] fine-grain QoS Cc: ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> References: <3CA8B9C1.19799800@degree2.com> <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Relevant problem: Let emergency-related IP packets through a congested network. Proposed solution: use WRED to deal with congestion scenarios, with no drops of emergency-related IP packets (even though UDP and short TCP sessions won't throttle back). How it solves/addresses the problem: 1) doesn't require signaling ahead of time like RSVP (which can delay the session setup and be a processor/memory burden on congested boxes) 2) simple mechanism to let emergency-related IP packets through during congestion 3) May not help alleviate overall network congestion condition (and may actually make it worse if many UDP applications retransmit on delivery failure- not an issue for real-time apps), but it will certainly get emergency traffic through with greater reliability. 4) Delay/jitter performance for real-time emergency apps won't suffer much (from not getting moved to the front of a queue) unless there are huge buffer queues in high bandwidth interfaces; low-bandwidth links will absolutely require packet prioritization to solve delay/jitter performance issues. Regards, Scott At 01:30 PM 4/1/2002 -0800, Fred Baker wrote: >At 11:49 AM 4/1/2002, Alistair Munro wrote: >> From what I know of IP QoS, there are mechanisms to guarantee throughput >> for aggregates and flows. How would they be applied effectively for fine >> grain differentiation (large number of flows) under very high traffic >> intensities? > > > >But for elastic traffic, which represents O(95%) of Internet traffic, it >doesn't make sense. The median TCP session has <= 10 packets going each >way, and no concept of a rate, as there is only one actual data segment >each way. To try to set up call state as it exists in the telco world, and >make "per-call" guarantees, is to dramatically increase the message >traffic without materially changing much, and even to set up RSVP flow >state for such sessions is difficult as there is no concept of a rate - >and the guy requesting the rate has no concept of the amount of data he is >asking for. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 20:32:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20997 for ; Mon, 1 Apr 2002 20:32:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24926; Mon, 1 Apr 2002 20:28:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24894 for ; Mon, 1 Apr 2002 20:28:06 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20918 for ; Mon, 1 Apr 2002 20:28:02 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g321RTY21459; Mon, 1 Apr 2002 17:27:29 -0800 (PST) Message-Id: <5.1.0.14.2.20020401170636.02efd8c8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 17:14:25 -0800 To: Scott Keagy From: Fred Baker Subject: Re: [Ieprep] fine-grain QoS Cc: Alistair Munro , ieprep@ietf.org In-Reply-To: <4.3.2.7.2.20020401160211.0598d550@malone.cisco.com> References: <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> <3CA8B9C1.19799800@degree2.com> <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org that actually sounds a lot like section 2.4 of http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt, which describes classes of traffic in the diffserv architecture and how they might be used. What would be necessary would be to ensure that traffic marked with the higher drop probabilities never included emergency traffic; we would need to discuss how that might be achieved. The adoption of RFC 3168 would make it a lot easier, as apart from the open SYN/SYN-ACK packets it doesn't drop traffic in response to congestion, it marks it as having experienced congestion. At 04:39 PM 4/1/2002, Scott Keagy wrote: >Relevant problem: Let emergency-related IP packets through a congested >network. > >Proposed solution: use WRED to deal with congestion scenarios, with no >drops of emergency-related IP packets (even though UDP and short TCP >sessions won't throttle back). > >How it solves/addresses the problem: >1) doesn't require signaling ahead of time like RSVP (which can delay the >session setup and be a processor/memory burden on congested boxes) >2) simple mechanism to let emergency-related IP packets through during >congestion >3) May not help alleviate overall network congestion condition (and may >actually make it worse if many UDP applications retransmit on delivery >failure- not an issue for real-time apps), but it will certainly get >emergency traffic through with greater reliability. >4) Delay/jitter performance for real-time emergency apps won't suffer much >(from not getting moved to the front of a queue) unless there are huge >buffer queues in high bandwidth interfaces; low-bandwidth links will >absolutely require packet prioritization to solve delay/jitter performance >issues. > >Regards, >Scott > >At 01:30 PM 4/1/2002 -0800, Fred Baker wrote: >>At 11:49 AM 4/1/2002, Alistair Munro wrote: >>> From what I know of IP QoS, there are mechanisms to guarantee >>> throughput for aggregates and flows. How would they be applied >>> effectively for fine grain differentiation (large number of flows) >>> under very high traffic intensities? >> >> >> >>But for elastic traffic, which represents O(95%) of Internet traffic, it >>doesn't make sense. The median TCP session has <= 10 packets going each >>way, and no concept of a rate, as there is only one actual data segment >>each way. To try to set up call state as it exists in the telco world, >>and make "per-call" guarantees, is to dramatically increase the message >>traffic without materially changing much, and even to set up RSVP flow >>state for such sessions is difficult as there is no concept of a rate - >>and the guy requesting the rate has no concept of the amount of data he >>is asking for. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 1 22:46:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25277 for ; Mon, 1 Apr 2002 22:46:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01555; Mon, 1 Apr 2002 22:38:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01525 for ; Mon, 1 Apr 2002 22:38:29 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25033 for ; Mon, 1 Apr 2002 22:38:26 -0500 (EST) Received: from [24.28.197.67] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1331343; Mon, 01 Apr 2002 22:38:22 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] fine-grain QoS To: Scott Keagy , Fred Baker , Alistair Munro Cc: ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 01 Apr 2002 22:38:22 -0500 Message-ID: In-Reply-To: <4.3.2.7.2.20020401160211.0598d550@malone.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Mon, 01 Apr 2002 16:39:51 -0800 Scott Keagy wrote: > Relevant problem: Let emergency-related IP packets > through a congested network. Dear Scott; I am afraid that I do not understand how this is supposed to work. RED and WRED drop packets early to "alert" TCP of upcoming congestion. I am guessing that you mean to not subject the "emergency" packets to the early loss procedures. But 1.) how do you let routers know which packets are "emergency" ? and 2.) When the congestion occurs, the packets have to be lost for real. What happens when "emergency" packets are received without room in the queue ? Are there separate queues for the "emergency" packets ? 3.) What is the authority for setting emergency packets ? How is this information propagated ? I do not understand how you could avoid the complications of RSVP, or even why this would be superior. Regards Marshall Eubanks > > Proposed solution: use WRED to deal with congestion > scenarios, with no > drops of emergency-related IP packets (even though UDP > and short TCP > sessions won't throttle back). > > How it solves/addresses the problem: > 1) doesn't require signaling ahead of time like RSVP > (which can delay the > session setup and be a processor/memory burden on > congested boxes) > 2) simple mechanism to let emergency-related IP packets > through during > congestion > 3) May not help alleviate overall network congestion > condition (and may > actually make it worse if many UDP applications > retransmit on delivery > failure- not an issue for real-time apps), but it will > certainly get > emergency traffic through with greater reliability. > 4) Delay/jitter performance for real-time emergency apps > won't suffer much > (from not getting moved to the front of a queue) unless > there are huge > buffer queues in high bandwidth interfaces; low-bandwidth > links will > absolutely require packet prioritization to solve > delay/jitter performance > issues. > > Regards, > Scott > > At 01:30 PM 4/1/2002 -0800, Fred Baker wrote: > >At 11:49 AM 4/1/2002, Alistair Munro wrote: > >> From what I know of IP QoS, there are mechanisms to > guarantee throughput > >> for aggregates and flows. How would they be applied > effectively for fine > >> grain differentiation (large number of flows) under > very high traffic > >> intensities? > > > > > > > >But for elastic traffic, which represents O(95%) of > Internet traffic, it > >doesn't make sense. The median TCP session has <= 10 > packets going each > >way, and no concept of a rate, as there is only one > actual data segment > >each way. To try to set up call state as it exists in > the telco world, and > >make "per-call" guarantees, is to dramatically increase > the message > >traffic without materially changing much, and even to > set up RSVP flow > >state for such sessions is difficult as there is no > concept of a rate - > >and the guy requesting the rate has no concept of the > amount of data he is > >asking for. > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Tue Apr 2 01:42:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29857 for ; Tue, 2 Apr 2002 01:42:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20053; Tue, 2 Apr 2002 01:36:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20019 for ; Tue, 2 Apr 2002 01:36:10 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29703 for ; Tue, 2 Apr 2002 01:36:08 -0500 (EST) Received: from [24.28.197.67] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1331385; Tue, 02 Apr 2002 01:35:03 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] a little homily To: Fred Baker , ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Tue, 02 Apr 2002 01:35:03 -0500 Message-ID: In-Reply-To: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Dear Fred; I thought I should respond to this. I first became aware of this WG in the run up to the last IETF. After 9/11, I became part of a working group in the International Webcasting Association, seeking to publicize the useful of multicast videocasting (i.e., webcasting) in emergency situations. The charter of this WG states -The working group will develop a BCP RFC or set of RFCs, -regarding operational implementation of services for -Emergency Preparedness using existing Internet protocols. which seems to render on topic not just the hardening of existing and wide-spread applications, such as e-mail, but also consideration of relatively new applications such as VOIP and multicast, and how they might relate to emergency communications. As I have been working on such matters since October, I thought that I might be able to contribute to the WG, not just on matters multicast, but in general. It was certainly not my intention to stir up any trouble. However, we have been discussing the application of multicast to emergency communications, and, as such, this seemed and still seems relevent to the charter of this working group. On Mon, 01 Apr 2002 08:30:00 -0800 Fred Baker wrote: > We certainly need to be able to do our best, and any > useful tool to counter > a credible threat is a good thing to do. > > I am going to explain my reasoning with respect to > multicast and a special > multicast group of addresses. Please understand that I am > all for multicast > as a technology, and I am aware of other proposals on the > table. These are > examples, symptoms; I want to use them to address my > underlying concern. > > Let me give you an insurance analogy. In Florida, one can > insure one's home > and property against a number of threats, including fire > and hurricane > damage. In California, where I live, one can insure one's > home and property > against a number of threats, including fire and > earthquake damage. I don't > know whether they sell earthquake insurance in Florida; I > can tell you that > they don't sell hurricane damage insurance for residences > in California. > The reason they don't sell it is because there is no > credible threat - > that's not a problem we have in California. > > Over the past week, we have had a presentation by someone > who said he was > writing a draft about multicast, and we have discussed > the possible > assignment of a set of class D addresses to emergency > workers in case they > can't get them during an emergency. > > In the Class D space, there are 2^24 (roughly 16 million) > addresses, of > which 2^20 (about one million) are specified as general > multicast addresses > routable by such protocols as PIM and DVMRP. In the past > decade, it is > unlikely that more than a hundred have been in use at any > given time, > because IP multicast is not heavily used in the > commercial Internet, or > anywhere else. Due to the low level of use, service > providers do not > routinely go to the effort to configure the capability - > they don't see > revenue in response to the effort. The evidence that > there is a credible > threat in the class D multicast address space is not in > the least obvious. > Multicasting has a working address allocation system which is actually considerably used - the RFC 3180 "GLOP" address space. Most of the 1 to 3 thousand "permanent" groups that have been present in the last year have group addresses coming from this range. Perusal of the multicast status page that we maintain http://www.multicasttech.com/status/index.html shows that multicast deployment is of order 5 to 15% of the entire Internet. Perusal of the multicast AS list http://www.multicasttech.com/status/mbgp.sum shows that most of the "backbone" providers have at least some support for multicast. I do not think that it is the job for the IETF or a WG to tell ISP's to adopt multicast, any more than for any new technology. However, it is germane to say that certain technologies are better or worse for certain applications under certain circumstances, and that, in the proper scope, it seems to me fails squarely in the working group charter. > And by the way, the folks looking at IP Multicast during > an emergency, > according to all reports, are not emergency workers. > Emergency workers > could presumably use video teleconferencing for certain > cases, but in a > case where we're really happy to be making audio calls > work, that's not the > top of anyone's agenda that has commented to this working > group. Emergency > workers don't use IP multicast, or if they do they > haven't bothered to > report the fact. > I do not see that this is germane. I am sure that they are not, by and large, aware of multicasting. They are not aware of VOIP either, nor of the differences between packet and circuit switching. That is our job, not theirs. The charter for this WG talks about the rapid evolution of the "commercial telecommunications infrastructure" to the Internet, which implicitly, at least, includes video. The emergency workers that I have talked to have expressed interest in Internet video (as in video from the scene, rather than videoconferencing). This is, by and large, a new capability for them. I feel certain that this technology will be used as it becomes available and wireless packet switched communications becomes more ubiquitous. So I would certainly regard recommendations by the working group as to what sort of video transport is suitable as consistent with the charter of the WG. Finally, communications between the emergency infrastructure and the populace are certainly part of emergency preparedness. Again, I would regard recommendations by the working group as to the best way to do this as consistent with the charter of the WG. > So these proposals come: > - in the complete absence of utility in contemplated > emergency communications > - without any evidence of a credible threat > - in a widespread absence of commercial deployment > - when these points were questioned (by me), without > even an attempt to > justify them. > > However, if the proposal goes forward, what I hear is a > requirement to > assign addresses that will not be used to applications > which do not exist, > and a requirement for ~10,000 service providers > world-wide to expend money > on infrastructure for emergency communications which will > not in fact be used. > > This is a waste of money, and an excellent argument for > the people who read > the recommendations of this working group to dismiss them > out of hand, as > silly and ill-considered. > > If you want the output of this working group to have an > affect, any effect > whatsoever, on what people do to support emergency > telecommunications, the > output has to be credible, and this is not. > > If you want the discussion to be relevant, I have two > words for you: > > GGGG EEEEEE TTTTTTT RRRRRR EEEEEE A L > GG GG E T RR RR E A A L > GG EEE T RR RR EEE A A L > GG GGG E T RRRRR E AAAAAAA L > GG GG E T RR RR E A A L > GGGG EEEEEE T RR RR EEEEEE A A > LLLLLLL > > > Now, we know that in an emergency, a fair bit of traffic > can be generated, > causing a massive and sudden congestive collapse. This > can happen in three > ways: > > - telephone switches (PSTN and IP) can be so overloaded > that they are forced > to ignore calls while they serve the ones they have > - data application servers can be overloaded to such an > extent that they > are unable to support the load > - data trunks can be overloaded in such a way that they > drop a lot of traffic > > We can, realistically, look at the issues in these cases > and ensure that > they are covered. This requires a gap analysis and > framework for emergency > telephone switching; this is a chartered deliverable of > this working group. > It also requires a recommendation for the management of > data traffic using > elastic applications; this likewise is a chartered > deliverable of this > working group. > > If there are other credible threats, we need to surface > them, and we need > to make recommendations concerning them. > > Interesting solutions that meet no credible threat are > out of scope. So any > proposal of a solution to a problem needs to identify > what threat it > counters, and demonstrate that the threat is credible. > Anything which does > not do so is a waste of all of our time. > > I dunno, may you would spend money on Hurricane insurance > in California. I > wouldn't, and I don't want this working group expending > time and energy on > that class of threat. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep I have no intention in further describing multicast technology or deployment in this list except as is relevant to future discussions (I would be glad to respond to questions or comments either off list or on MBONED, if anyone wants to pursue them). However, I thought that it might be useful for me to comment upon certain of the issues raised in your previous e-mail as to the scope of the WG. If the working group and the area chairs feel that the scope of the WG is indeed limited to the telephony aspects of telecommunications, then so be it. Fond Regards Marshall Eubanks _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 06:41:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12232 for ; Tue, 2 Apr 2002 06:41:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05386; Tue, 2 Apr 2002 06:40:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05356 for ; Tue, 2 Apr 2002 06:40:10 -0500 (EST) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12224 for ; Tue, 2 Apr 2002 06:40:04 -0500 (EST) Received: from degree2.com (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g32Bds323407; Tue, 2 Apr 2002 12:39:54 +0100 Message-ID: <3CA99980.1070004@degree2.com> Date: Tue, 02 Apr 2002 12:44:00 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org Subject: Re: [Ieprep] Folts' stated requirements: mobility References: <5.1.0.14.2.20020401085850.01ea6260@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401131858.022f58d0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > We have, however, been asked to make recommendations about how those > RFIs/RFPs might be structured, and how people might deploy or use the > resulting service. In respect of mobility, there are multiple solutions, IP and sub-IP. A discriminator for choosing to deploy one or another is reachability, which is part of availability. Reachability of portable IP-only terminals used by emergency personnel that are highly mobile in the emergency area and changing subnetwork at a high rate will be affected by the solution chosen. $$ or $$$$ may also have an influence but I was not thinking about $ principally - emergency services are not a commodity, although we may succeed in opening this opportunity. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 08:59:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15327 for ; Tue, 2 Apr 2002 08:59:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12715; Tue, 2 Apr 2002 08:59:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12662 for ; Tue, 2 Apr 2002 08:59:07 -0500 (EST) Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15231 for ; Tue, 2 Apr 2002 08:59:04 -0500 (EST) Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 2 Apr 2002 13:59:06 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 2 Apr 2002 08:58:44 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002040208583618611 ; Tue, 02 Apr 2002 08:58:36 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 08:59:19 -0500 Message-Id: From: "King, Kimberly S." To: "'Fred Baker'" Cc: "'ieprep@ietf.org'" Subject: RE: [Ieprep] a little homily Date: Tue, 2 Apr 2002 08:58:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Fred, "- data application servers can be overloaded to such an extent that they are unable to support the load" What do you think? Suppose emergency workers just HAVE to have access to CNN.com (or other sites) during an emergency but the CNN application servers get overloaded. Suppose prioritizing and distinguishing emergency requests from others is not in the "GET REAL" category. Can't the Government strike a deal with CNN to have them email (or upload) the content on some private site especially reserved for the emergency users at periodic intervals during emergencies? The Government could strike a deal with a number of such providers and then specifically put up the information deemed most appropriate. Perhaps this would avoid the rush of CNN because the private servers are hidden from the general population (can we do this?). Perhaps emergency workers could be given the URL of the private site much like a GETS card. Kimberly > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Monday, April 01, 2002 11:30 AM > To: ieprep@ietf.org > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] a little homily > > > We certainly need to be able to do our best, and any useful > tool to counter > a credible threat is a good thing to do. > > I am going to explain my reasoning with respect to multicast > and a special > multicast group of addresses. Please understand that I am all > for multicast > as a technology, and I am aware of other proposals on the > table. These are > examples, symptoms; I want to use them to address my > underlying concern. > > Let me give you an insurance analogy. In Florida, one can > insure one's home > and property against a number of threats, including fire and > hurricane > damage. In California, where I live, one can insure one's > home and property > against a number of threats, including fire and earthquake > damage. I don't > know whether they sell earthquake insurance in Florida; I can > tell you that > they don't sell hurricane damage insurance for residences in > California. > The reason they don't sell it is because there is no credible > threat - > that's not a problem we have in California. > > Over the past week, we have had a presentation by someone who > said he was > writing a draft about multicast, and we have discussed the possible > assignment of a set of class D addresses to emergency workers > in case they > can't get them during an emergency. > > In the Class D space, there are 2^24 (roughly 16 million) > addresses, of > which 2^20 (about one million) are specified as general > multicast addresses > routable by such protocols as PIM and DVMRP. In the past > decade, it is > unlikely that more than a hundred have been in use at any given time, > because IP multicast is not heavily used in the commercial > Internet, or > anywhere else. Due to the low level of use, service providers do not > routinely go to the effort to configure the capability - they > don't see > revenue in response to the effort. The evidence that there is > a credible > threat in the class D multicast address space is not in the > least obvious. > > And by the way, the folks looking at IP Multicast during an > emergency, > according to all reports, are not emergency workers. > Emergency workers > could presumably use video teleconferencing for certain > cases, but in a > case where we're really happy to be making audio calls work, > that's not the > top of anyone's agenda that has commented to this working > group. Emergency > workers don't use IP multicast, or if they do they haven't > bothered to > report the fact. > > So these proposals come: > - in the complete absence of utility in contemplated > emergency communications > - without any evidence of a credible threat > - in a widespread absence of commercial deployment > - when these points were questioned (by me), without even > an attempt to > justify them. > > However, if the proposal goes forward, what I hear is a > requirement to > assign addresses that will not be used to applications which > do not exist, > and a requirement for ~10,000 service providers world-wide to > expend money > on infrastructure for emergency communications which will not > in fact be used. > > This is a waste of money, and an excellent argument for the > people who read > the recommendations of this working group to dismiss them out > of hand, as > silly and ill-considered. > > If you want the output of this working group to have an > affect, any effect > whatsoever, on what people do to support emergency > telecommunications, the > output has to be credible, and this is not. > > If you want the discussion to be relevant, I have two words for you: > > GGGG EEEEEE TTTTTTT RRRRRR EEEEEE A L > GG GG E T RR RR E A A L > GG EEE T RR RR EEE A A L > GG GGG E T RRRRR E AAAAAAA L > GG GG E T RR RR E A A L > GGGG EEEEEE T RR RR EEEEEE A A LLLLLLL > > > Now, we know that in an emergency, a fair bit of traffic can > be generated, > causing a massive and sudden congestive collapse. This can > happen in three > ways: > > - telephone switches (PSTN and IP) can be so overloaded > that they are forced > to ignore calls while they serve the ones they have > - data application servers can be overloaded to such an > extent that they > are unable to support the load > - data trunks can be overloaded in such a way that they > drop a lot of traffic > > We can, realistically, look at the issues in these cases and > ensure that > they are covered. This requires a gap analysis and framework > for emergency > telephone switching; this is a chartered deliverable of this > working group. > It also requires a recommendation for the management of data > traffic using > elastic applications; this likewise is a chartered > deliverable of this > working group. > > If there are other credible threats, we need to surface them, > and we need > to make recommendations concerning them. > > Interesting solutions that meet no credible threat are out of > scope. So any > proposal of a solution to a problem needs to identify what threat it > counters, and demonstrate that the threat is credible. > Anything which does > not do so is a waste of all of our time. > > I dunno, may you would spend money on Hurricane insurance in > California. I > wouldn't, and I don't want this working group expending time > and energy on > that class of threat. > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Tue Apr 2 11:04:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20508 for ; Tue, 2 Apr 2002 11:04:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21233; Tue, 2 Apr 2002 11:03:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21199 for ; Tue, 2 Apr 2002 11:03:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20440 for ; Tue, 2 Apr 2002 11:03:37 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32G36b23070; Tue, 2 Apr 2002 08:03:06 -0800 (PST) Message-Id: <5.1.0.14.2.20020401085852.01d7ae30@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 08:03:00 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Folts' stated requirements: Non-Traceability Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org In http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, you state that "A US Government working group recently identified fourteen basic functional requirements for the future ETS." Could you please help me, specifically, with item (c) in section 2: >c. Non-Traceability Selected users must be able to use NS/EP > services without risk of usage being > traced (i.e., without risk of user or > location being identified). What is the specific problem that this is addressing? Under what circumstances does an emergency worker need to be able to address emergency issues without disclosing his or he identity or location? Doesn't this militate against point (b), in which you identify that emergency services need to be secured against threats such as unauthorized use? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 11:15:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21094 for ; Tue, 2 Apr 2002 11:15:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21828; Tue, 2 Apr 2002 11:14:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21792 for ; Tue, 2 Apr 2002 11:14:37 -0500 (EST) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21037 for ; Tue, 2 Apr 2002 11:14:31 -0500 (EST) Received: from degree2.com (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g32GEN327295; Tue, 2 Apr 2002 17:14:23 +0100 Message-ID: <3CA9D9D6.6040006@degree2.com> Date: Tue, 02 Apr 2002 17:18:30 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org Subject: Re: [Ieprep] fine-grain QoS References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, >> From what I know of IP QoS, there are mechanisms to guarantee >> throughput for aggregates and flows. How would they be applied >> effectively for fine grain differentiation (large number of flows) >> under very high traffic intensities? > > You might read RFC 3246. > > Fine grain QoS is a non-goal in IP. Goal or not, it is possible according to RFC 3246. However, I don't know if the strategies indicated in RFC 3246 would meet the requirements of IEPREP if one were to grub around inside the aggregate. RFC 2998 gives a better big picture IMO. However the main issue is that we expect to be operating at an extreme of traffic intensity at which point RED may start to have an effect too. The outline configuration you propose in http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt , section 2.4, would disadvantage some signalling traffic. I would put signalling related to voice/video set-up (H.323, SIP) in AF4. As it happens, in my (admittedly small but deliberately overloaded) voice/video network, I put signalling and call traffic (inc. in-band RSVP) in two EF aggregates (signalling given a higher quality service) - I believe that putting it in AF3 runs the risk of losing it or demoting it further. In conditions of heavy congestion anything in the lower ranks of AF will suffer. The configuration would be fine I think for a purpose built IP emergency network but not for a multi-service public ISP. I am not keen on adding codepoints to differentiate emergency traffic for the latter case and, from previous comments, I'm not sure if the latter is being considered or not. > If you trace the signal flow in H.323, the process of setting up a > call requires something on the order of 50 messages, .... > So we actively avoided the question for elastic traffic, and in the > case of inelastic voice/video traffic, enable you to negotiate the > bandwidth using RSVP. Not sure about all this other stuff - tutorial or not, it may, or may not, be needed as we examine the requirements in more detail. I hope not. The number of messages exchanged by H.323 or SIP is a fact, to be taken into account because we will be using one or the other or both. TCP rate control by bandwidth limiting or ECN may be useful in the IEPREP, or not - I don't know if the 95% status-quo of short transactions will apply at this stage. Again, I suspect, and hope, it will as the damage may have been done by a long-lived TCP "session" by the time edge-mechanisms kick in. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.degree2.com, http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 14:01:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28167 for ; Tue, 2 Apr 2002 14:01:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05687; Tue, 2 Apr 2002 13:58:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05657 for ; Tue, 2 Apr 2002 13:58:23 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28051 for ; Tue, 2 Apr 2002 13:58:21 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50D05A>; Tue, 2 Apr 2002 13:36:18 -0500 Message-ID: From: "Folts, Harold" To: "'Gunn, Janet NE'" , "'James M. Polk'" , ieprep Subject: RE: [Ieprep] Preemption Date: Tue, 2 Apr 2002 13:36:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA75.4611B940" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA75.4611B940 Content-Type: text/plain; charset="iso-8859-1" Janet, Just catching up with my Email. I think that your input below is excellent and right on the money. Hal -----Original Message----- From: Gunn, Janet NE [mailto:Janet.Gunn@DynCorp.com] Sent: Monday, March 18, 2002 10:51 PM To: 'James M. Polk'; ieprep Subject: RE: [Ieprep] Preemption I think the thing to remember is that pre-emption is permitted (on the PSTN) in some nations and not permitted in others. So it seems the first objective is not to REQUIRE anything that would look like pre-emption when integrated with the PSTN in those countries. In other countries (and private networks) where (telephony) pre-emption is permitted, it MAY be permissible to allow (but not require) something that looks like pre-emption. As an analogy, e-MLPP (in a GSM mobile network) allows pre-emption in those juristictions which allow it, but does not require it in juristictions which do not permit pre-emption. In the telephony context, pre-emption refers to the "call". So it is possible that some types of packet level pre-emption (or selective packet dropping) may be acceptable even in those contexts where call level pre-emption is not permitted. This would presumably be governed by SLAs for QoS. Janet Gunn -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, March 18, 2002 8:46 PM To: ieprep Subject: Re: [Ieprep] Preemption At 01:15 AM 3/19/2002 +0000, Ken Carlberg wrote: >Cory, > > >> In the IP Telephony Framework draft, non-preemptive action is stated >> as a primary objective. As there is ongoing work *with* preemption (MLPP and Assured Services) that has been frequently brought up in discussions on this list, stating that *a* default objective is "non-preemptive" is appropriate IMO. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1DA75.4611B940 Content-Type: text/html; charset="iso-8859-1"
Janet,
 
Just catching up with my Email.  I think that your input below is excellent and right on the money.
 
Hal
-----Original Message-----
From: Gunn, Janet NE [mailto:Janet.Gunn@DynCorp.com]
Sent: Monday, March 18, 2002 10:51 PM
To: 'James M. Polk'; ieprep
Subject: RE: [Ieprep] Preemption

I think the thing to remember is that pre-emption is permitted (on the PSTN) in some nations and not permitted in others.
So it seems the first objective is not to REQUIRE anything that would look like pre-emption when integrated with the PSTN in those countries.  In other countries (and private networks) where (telephony) pre-emption is permitted, it MAY be permissible to allow (but not require) something that looks like pre-emption.
 
As an analogy, e-MLPP (in a GSM mobile network) allows pre-emption in those juristictions which allow it, but does not require it in juristictions which do not permit pre-emption.
 
In the telephony context, pre-emption refers to the "call".  So it is possible that some types of packet level pre-emption (or selective packet dropping) may be acceptable even in those contexts where call level pre-emption is not permitted.  This would presumably be governed by SLAs for QoS.
 
Janet Gunn
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, March 18, 2002 8:46 PM
To: ieprep
Subject: Re: [Ieprep] Preemption

At 01:15 AM 3/19/2002 +0000, Ken Carlberg wrote:
>Cory,
>
>
>> In the IP Telephony Framework draft, non-preemptive action is stated
>> as a primary objective. 

As there is ongoing work *with* preemption (MLPP and Assured Services) that has been frequently brought up in discussions on this list, stating that *a* default objective is "non-preemptive" is appropriate IMO.

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
------_=_NextPart_001_01C1DA75.4611B940-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 14:55:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00144 for ; Tue, 2 Apr 2002 14:55:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09108; Tue, 2 Apr 2002 14:54:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09073 for ; Tue, 2 Apr 2002 14:54:32 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00099 for ; Tue, 2 Apr 2002 14:54:29 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32Jrtb08808; Tue, 2 Apr 2002 11:53:55 -0800 (PST) Message-Id: <5.1.0.14.2.20020402113306.05939df0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 11:42:54 -0800 To: "Marshall Eubanks" From: Fred Baker Subject: Re: [Ieprep] a little homily Cc: ieprep@ietf.org In-Reply-To: References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:35 PM 4/1/2002, Marshall Eubanks wrote: >If the working group and the area chairs feel that the scope of the WG is >indeed limited to the telephony aspects of telecommunications, then so be it. the working group is not limited to the telephony aspects. It is, however, chartered to write requirements targeted at solving problems that are preventing the Internet from being used in an emergency services infrastructure, not to be a fishing expedition. Let's take Ken's comment yesterday, that multicast might be useful for VoIP and video on IP for emergency workers. VoIP has certain requirements for emergency workers, in the sense that if there is a choice between a VoIP call that will help manage the emergency getting through and some other call getting through, one wants the emergency-useful call to go through. VoIP-for-emergency also has all the usual issues of VoIP - the QoS better be there, by whatever means. Now, when we want to have a teleconference among various people at disparate locations, we will want to use multicast routing to do that. But the issues here are not for multicast per se, they are for the voice/video application that happens to be in use, and they are the same issues as apply to point to point calls. So, with anything we discuss, the point in *this* working group needs to be the coupling of a problem and a solution, not just "I have a great idea." With a million addresses available to be used at any given time, and by your estimate a few thousand actually in use, I don't see a problem. We're here to do solid engineering, not marketing. We're asking people to spend money; there better be a bang we get for those bucks, or the bucks will not be spent and we will be deemed irrelevant. That's my point. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 14:57:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00224 for ; Tue, 2 Apr 2002 14:57:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09061; Tue, 2 Apr 2002 14:54:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09029 for ; Tue, 2 Apr 2002 14:54:06 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00069 for ; Tue, 2 Apr 2002 14:54:04 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B501CC7>; Tue, 2 Apr 2002 14:54:04 -0500 Message-ID: From: "Folts, Harold" To: "'goldmans@agcs.com'" , Ken Carlberg Cc: ieprep Subject: RE: [Ieprep] Preemption Date: Tue, 2 Apr 2002 14:53:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Yep > -----Original Message----- > From: Stuart (Stu) Goldman [mailto:goldmans@agcs.com] > Sent: Sunday, March 24, 2002 10:41 PM > To: Ken Carlberg > Cc: ieprep > Subject: Re: [Ieprep] Preemption > > > Ken, > > If I correctly understand what you have written, you are > suggesting non > pre-emption is the default, but are not preventing > pre-emption (but not as the > default) in those networks where it might be desired. > > This sounds like an approach that everybody should be able to > live with. > > > Ken Carlberg wrote: > > > > >IMHO we just should take no position about preemption in > the framework > > > >document. > > > > > > I personally agree, if you're talking about call > pre-emption. The framework > > > should indicate that there will be policies applied in > various networks, > > > and that the exact structure of the policy is a matter of > service offering > > > and contract between the network provider and its > customers. Pre-emption or > > > lack of it is a policy which would be applied in a > specific network, and on > > > this list there has been discussion both of a network > that does use it and > > > a network that doesn't use it. > > > > as it is written now, the Framework document takes the position that > > non-preemptive service is the default service or mode of operation. > > > > there were a couple of thoughts behind this approach. the current > > deployed effort in IP telephony does not support > pre-emption. hence, > > using this installed base as the default model would seem > to be a nice > > starting point -- much in the way that the inclusion of new service > > models in IP still led the IETF to take the position that > best effort > > is the default service model for IP. > > > > it also seemed that pre-emptive service in non-private > networks involves > > a combination of local law/regulation as well as additional > mechanisms > > that go beyond just labeling. so, if we state that if for > some reason a > > lack of policy exists in a network for the received label, then the > > default action taken should be non-preemptive. thereby further > > reinforcing the distinction between label and the action > taken upon it. > > > > i believe the framework document already articulates what Fred says > > above about policies, but i'll double check to make sure. > > > > -ken > > > > _______________________________________________ > > 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 From ieprep-admin@ietf.org Tue Apr 2 15:10:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00847 for ; Tue, 2 Apr 2002 15:10:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10295; Tue, 2 Apr 2002 15:08:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10240 for ; Tue, 2 Apr 2002 15:08:25 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00735 for ; Tue, 2 Apr 2002 15:08:23 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32K7nb20265; Tue, 2 Apr 2002 12:07:49 -0800 (PST) Message-Id: <5.1.0.14.2.20020401084938.01ed3810@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 12:07:44 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Folts' stated requirements - voiceband and broadband services Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org In http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, you state that "A US Government working group recently identified fourteen basic functional requirements for the future ETS." In section 2, you state that there is a requirement for +---------------------------------------------------------------- |j. Voice Band Service The service must provide voice band | service in support of presidential and | other communications. +---------------------------------------------------------------- |k. Broadband Service The service must provide broadband | service in support of NS/EP missions | (e.g., video, imaging, web access, | multimedia). +---------------------------------------------------------------- It's not clear to me what you are calling for here. Are you asking for the network to have built-in services that provide, for example, TV-like broadcast capabilities? Are you looking for the ability to place VoIP phone calls? Specifically what problems do you see needing solution in this arena? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 15:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00909 for ; Tue, 2 Apr 2002 15:10:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10130; Tue, 2 Apr 2002 15:05:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10092 for ; Tue, 2 Apr 2002 15:05:32 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00591 for ; Tue, 2 Apr 2002 15:05:25 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32K4fb17787; Tue, 2 Apr 2002 12:04:48 -0800 (PST) Message-Id: <5.1.0.14.2.20020402114443.030ffad8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 12:00:18 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] fine-grain QoS Cc: ieprep@ietf.org In-Reply-To: <3CA9D9D6.6040006@degree2.com> References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 08:18 AM 4/2/2002, Alistair Munro wrote: >The outline configuration you propose in >http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt >, section 2.4, would disadvantage some signalling traffic. I would put >signalling related to voice/video set-up (H.323, SIP) in AF4. I'm confuse by this statement. AF is defined by http://www.ietf.org/rfc/rfc2597.txt, which I would encourage you to read. It defines four classes of traffic, which a network administration assigns bandwidth to individually. If I have a video stream which will average 7 MBPS, let's say, I would tag it as AF4 (I would give it the AF41 code point, and a subsequent metering point might re-assign any traffic over 7 MBPS as AF42, but they would go through the same queue), and I would provision the queue to handle >=7 MBPS. If I am provisioning the network for 100 simultaneous VoIP calls, and each call occupies (let's say) 90 KBPS of IP traffic, I would also provision a priority queue (as opposed to a rate-based queue) into which I would put the EF traffic, and I would police the input to that queue, dropping traffic in excess of 9000 KBPS (9 MBPS) in either direction on a link; I would also want an RSVP registration of the bandwidth. Suppose that the network administration measures that there is a standing load of 100 KBPS of signalling traffic going along with the AF4 and EF traffic. I would expect it might provision the AF3 queue to have 250 KBPS of capacity for same. The net result would be that little if any signalling traffic is delayed, much less dropped, even if AF4 is getting completely hosed, and even if we are refusing calls to place traffic into the EF queue, because the 250 KBPS traffic bound is not being crossed. The different diffserv classes are as separate as if they were on separate lines, except for the fact that if one is not using its bandwidth at the moment the other might temporarily use it. > As it happens, in my (admittedly small but deliberately overloaded) > voice/video network, I put signalling and call traffic (inc. in-band > RSVP) in two EF aggregates (signalling given a higher quality service) - > I believe that putting it in AF3 runs the risk of losing it or demoting > it further. In conditions of heavy congestion anything in the lower ranks > of AF will suffer. Your comment leads me to believe that you are under the (unfortunately common) misunderstanding that the classes of traffic are somehow priorities, and that AF4 would therefore shove AF3 out of the way. Are you under this misunderstanding? That's not how rate-based policies work. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 15:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00961 for ; Tue, 2 Apr 2002 15:12:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10238; Tue, 2 Apr 2002 15:08:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10204 for ; Tue, 2 Apr 2002 15:08:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00733 for ; Tue, 2 Apr 2002 15:08:20 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32K7nb20273; Tue, 2 Apr 2002 12:07:50 -0800 (PST) Message-Id: <5.1.0.14.2.20020401085848.01d76788@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 12:07:44 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Folts' stated requirements: security Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org In http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, you state that "A US Government working group recently identified fourteen basic functional requirements for the future ETS." In section 2, you bring up the issue of security: +---------------------------------------------------------------- |b. Secure Networks Networks must have protection against | corruption of, or unauthorized access to, | traffic and control, including expanded | encryption techniques and user | authentication, as appropriate. +---------------------------------------------------------------- I'm not just certain what direction you want to take this. It is understandable in the sense of motherhood and apple pie: "people shouldn't be able to disrupt my communications, especially when I am calling for a fire truck, and people shouldn't be able to simulate calls for fire trucks when there is no need for one." The question we need to ask is "so who needs to implement what, and what problem that we have are you addressing when you prescribe that?" Your generic IP Service Provider, one readily argues, needs to be in control of his routers and switches. To accomplish this, we need good neighbor authentication between routers, and perhaps we need digital signatures on routes in some sense. In context, there has been quite a bit of work; OSPF, IS-IS, and RIPv2 each have built-in neighbor authentication using MD5 hashes. BGP uses RFC 2385 MD5 hashing for the same purpose. OSPF V3 uses IPSEC neighbor authentication, and the same has recently been proposed for BGP as well. On the digital signature side, Sandy Murphy designed RFC 2154, which has not been widely deployed for lack of interest from service providers, and Steve Kent et al have pushed the model in BGP (for example, http://www.net-tech.bbn.com/sbgp/sbgp-index.html). In short, I hear you arguing that people should not be able to compromise routing. Are you stating that there is a problem here which needs to be addressed, or simply observing that security would be a nice attribute to have? When it comes to user services such as AOL and various instant messaging platforms, there is also a requirement for user authentication and authorization to use services. There are also business requirements for same; one doesn't want people to use one's service if they are not going to pay for it. Are you stating that the type of authentication used for business purposes is inadequate for emergency use? Are you stating that you would like to be able to use https or some other "Secure" access technique to get to your IM provider? Are you saying that you want the provider to encrypt IM traffic internally? What problem are you addressing, and what are the details of the requirements relating to the problem? Much email and other access is directly from the user's desktop or laptop computer. Are you asking for security for the end computer? Do you mean that in the sense of the network preventing DOS attacks in some way? Are you asking for encryption and authentication services to be implemented on the laptop? Specifically what problem are you addressing and what types of solutions would meet the requirement? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 15:23:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01386 for ; Tue, 2 Apr 2002 15:23:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10954; Tue, 2 Apr 2002 15:22:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10920 for ; Tue, 2 Apr 2002 15:22:41 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01323 for ; Tue, 2 Apr 2002 15:22:38 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50QKCV>; Tue, 2 Apr 2002 15:21:47 -0500 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" , "Folts, Harold" Cc: ieprep@ietf.org Date: Tue, 2 Apr 2002 15:21:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: Folts' stated requirements: Non-Traceability Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, April 02, 2002 11:03 AM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: Folts' stated requirements: Non-Traceability > > > In > http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-p > aper-00.txt, > you state that "A US Government working group recently > identified fourteen > basic functional requirements for the future ETS." > > Could you please help me, specifically, with item (c) in section 2: > > >c. Non-Traceability Selected users must be able to use NS/EP > > services without risk of usage being > > traced (i.e., without risk of user or > > location being identified). > > What is the specific problem that this is addressing? Under what > circumstances does an emergency worker need to be able to > address emergency > issues without disclosing his or he identity or location? > Doesn't this > militate against point (b), in which you identify that > emergency services > need to be secured against threats such as unauthorized use? > The non-tracebility requirement only applies to certain government officials that could be involved in disaster recovery operations. Particularly this could apply to the "continuity of government" procedures. I have been told that fulfilling this requirement could be very difficult if not impossible in the internet environment. Nevertheless it is an objective to be considered. In addition, some ETS traffic might need to be encrypted to protect sensitive and confidential information. Neither of these would apply specifically to immediate recovery operations teams at the disaster site or operations center. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 15:24:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01429 for ; Tue, 2 Apr 2002 15:24:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11039; Tue, 2 Apr 2002 15:23:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10997 for ; Tue, 2 Apr 2002 15:23:13 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01348 for ; Tue, 2 Apr 2002 15:23:07 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA12637; Tue, 2 Apr 2002 12:19:22 -0800 (PST) Message-Id: <4.1.20020402140932.033247a0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 02 Apr 2002 14:18:52 -0600 To: Marshall Eubanks From: "James M. Polk" Subject: Re: [Ieprep] Public Safety? Cc: "Nguyen, An" , ieprep@ietf.org In-Reply-To: <3CA8C629.9090101@multicasttech.com> References: <4.1.20020401142133.0c510d70@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_920858324==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_920858324==_.ALT Content-Type: text/plain; charset="us-ascii" At 03:42 PM 4/1/2002 -0500, Marshall Eubanks wrote: >TESLA > >http://www.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt This will, in our case, call for a *single CA level* with a *single* root key for all emergency related agencies in order to intercommunicate (local police/Sheriff, State police, Fire, hospitals, private ambulance companies, FEMA, Red Cross, FBI, INS, Border Patrol, National Guard and then maybe the DOD).... unless I just misread this ID. That might be doable, and might be recommended as an output of this group -- but I don't believe that can become international in requirements/recommendations from this group and hope to see it happen in our lifetimes I could be wrong though.... ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_920858324==_.ALT Content-Type: text/html; charset="us-ascii"
At 03:42 PM 4/1/2002 -0500, Marshall Eubanks wrote:
>TESLA
>

This will, in our case, call for a *single CA level* with a *single* root key for all emergency related agencies in order to intercommunicate (local police/Sheriff, State police, Fire, hospitals, private ambulance companies, FEMA, Red Cross, FBI, INS, Border Patrol, National Guard and then maybe the DOD).... unless I just misread this ID. That might be doable, and might be recommended as an output of this group --  but I don't believe that can become international in requirements/recommendations from this group and hope to see it happen in our lifetimes

I could be wrong though....


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_920858324==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 16:08:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03524 for ; Tue, 2 Apr 2002 16:08:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13800; Tue, 2 Apr 2002 16:06:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13751 for ; Tue, 2 Apr 2002 16:06:08 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03493 for ; Tue, 2 Apr 2002 16:06:05 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32L5Sb03617; Tue, 2 Apr 2002 13:05:28 -0800 (PST) Message-Id: <5.1.0.14.2.20020402125056.059440f8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 13:01:20 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: Folts' stated requirements: Non-Traceability Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:21 PM 4/2/2002, Folts, Harold wrote: >I have been told that fulfilling this requirement could be very difficult if >not impossible in the internet environment. Nevertheless it is an objective >to be considered. In addition, some ETS traffic might need to be encrypted >to protect sensitive and confidential information. I'm not certain that it is impossible, or even difficult. Few internet devices know where they are now, so location hiding isn't a problem. It is possible to anonymize messages in various ways, usually by sending them to a server that forgets who sent it, manufactures a one-time identity, and resends the message. Of course, having done that, there is no telling who sent it. You would need an anonymous authenticator of some sort, such as putting a PGP signature on the email that was generated using a private key shared by the set of people authorized to use the service. From that perspective, this sounds like an attribute of the service that a service provider would set up under an appropriate contract. I don't think it is fundamental to the Internet, unless you care to convince me otherwise. In the lawful intercept discussion, a German contribution viewed anonymization of messages as a variety of unlawful activity - it was an attack in its own right. Several years back, Finland was a common place for anonymization servers to be sited; that stopped when Finland interpreted a law as saying that the anonymization server operator had to be able to respond to a subpoena by correlating messages sent from the server with their initiators. My humble opinion - this sounds like someone wanting to have their cake and eat it. Is an anonymization server OK, or is it not? But as to the fundamental attribute, I'm not sure what to do with the statements in your draft. Is there a technical issue that the IETF would respond to with a protocol? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 2 17:40:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06464 for ; Tue, 2 Apr 2002 17:40:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19472; Tue, 2 Apr 2002 17:40:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19404 for ; Tue, 2 Apr 2002 17:40:26 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06438 for ; Tue, 2 Apr 2002 17:40:22 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32Mdob19084; Tue, 2 Apr 2002 14:39:50 -0800 (PST) Received: from SKEAGY-W2K1.cisco.com (dhcp-171-69-95-88.cisco.com [171.69.95.88]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA15653; Tue, 2 Apr 2002 14:39:45 -0800 (PST) Message-Id: <4.3.2.7.2.20020402140351.02a15870@malone.cisco.com> X-Sender: skeagy@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Apr 2002 14:39:44 -0800 To: "Marshall Eubanks" , Fred Baker , Alistair Munro From: Scott Keagy Subject: Re: [Ieprep] fine-grain QoS Cc: ieprep@ietf.org In-Reply-To: References: <4.3.2.7.2.20020401160211.0598d550@malone.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org responses in-line At 10:38 PM 4/1/2002 -0500, Marshall Eubanks wrote: >On Mon, 01 Apr 2002 16:39:51 -0800 > Scott Keagy wrote: > > Relevant problem: Let emergency-related IP packets > > through a congested network. > >Dear Scott; > > I am afraid that I do not understand how this is supposed >to work. > >RED and WRED drop packets early to "alert" TCP of upcoming >congestion. I am guessing that you mean to not subject the >"emergency" packets to the early loss procedures. But Yes, selectively discard flows based on classified traffic. Example would be to let general HTTP / FTP traffic get progressively increasing drop rates based on increasing buffer depth thresholds, while emergency traffic is not dropped at all. It is primarily used to make TCP sessions back off and use slow-start mechanisms, but it can be useful as a low-overhead simple way to let emergency traffic through high bandwidth interfaces without regard to its impact on TCP backoff/slow-start or UDP impacts. The underlying principle in this approach would be "I'm not really trying to optimize congested network throughput, I'm just trying to make sure emergency services are fine". As I thought about this more, and about interaction with real-time apps (like telephony) that also would require preferential treatment with WRED, I convinced myself that prioritization of real-time emergency services vs. real-time normal services should not happen at packet level, but rather at call-control / session-control level (which has been discussed a lot earlier in this group). If you really want to stick with a packet-level approach for real-time services, then maybe set up normal voice services (and other real-time stuff) to get dropped only at high buffer depth thresholds, while emergency traffic is not dropped at all. Dropping plan would look something like this: Drop rate Drop rate Drop rate queue depth (normal) (real-time) (emergency) ========= ======= ======== ========= 25% 50% 0% 0% 50% 80% 0% 0% 75% 95% 50% 0% 90% 100% 75% 0% 99% 100% 100% 0% This is a gross oversimplification of queue depth ranges, and completely inaccurate/unverified drop rates, but it gets the concept across >1.) how do you let routers know which packets are >"emergency" ? and That is a separately scoped problem, with one potential solution being the use of DSCP marking. (other issues include trust of entity marking the packets but this is part of the "identifying emergency flows" problem"). >2.) When the congestion occurs, the packets have to be lost >for real. What happens when "emergency" packets are received >without room in the queue ? Are there separate queues for >the "emergency" packets ? That is the whole point of RED and WRED: proactive queue depth management. If WRED is working right, you should *never* have a full queue, so emergency traffic never faces this scenario. For a detailed discussion of this topic, check these links: http://www.icir.org/floyd/red.html I also talk about it from a variety of perspectives in "Integrating Voice and Data Networks" (link to appropriate table of contents section): http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/1578701961/reader/8/ (please excuse the blatant self-marketing) >3.) What is the authority for setting emergency packets ? >How is this information propagated ? Again, this is separately scoped issue. >I do not understand how you could avoid the complications of >RSVP, or even why this would be superior. I'm not trying to bring an end to RSVP. I'm just suggesting an alternative approach to explore; on this list we should find holes in this suggestion which would still require a more complicated solution (like RSVP). Regards, Scott >Regards >Marshall Eubanks > > > > > Proposed solution: use WRED to deal with congestion > > scenarios, with no > > drops of emergency-related IP packets (even though UDP > > and short TCP > > sessions won't throttle back). > > > > How it solves/addresses the problem: > > 1) doesn't require signaling ahead of time like RSVP > > (which can delay the > > session setup and be a processor/memory burden on > > congested boxes) > > 2) simple mechanism to let emergency-related IP packets > > through during > > congestion > > 3) May not help alleviate overall network congestion > > condition (and may > > actually make it worse if many UDP applications > > retransmit on delivery > > failure- not an issue for real-time apps), but it will > > certainly get > > emergency traffic through with greater reliability. > > 4) Delay/jitter performance for real-time emergency apps > > won't suffer much > > (from not getting moved to the front of a queue) unless > > there are huge > > buffer queues in high bandwidth interfaces; low-bandwidth > > links will > > absolutely require packet prioritization to solve > > delay/jitter performance > > issues. > > > > Regards, > > Scott > > > > At 01:30 PM 4/1/2002 -0800, Fred Baker wrote: > > >At 11:49 AM 4/1/2002, Alistair Munro wrote: > > >> From what I know of IP QoS, there are mechanisms to > > guarantee throughput > > >> for aggregates and flows. How would they be applied > > effectively for fine > > >> grain differentiation (large number of flows) under > > very high traffic > > >> intensities? > > > > > > > > > > > >But for elastic traffic, which represents O(95%) of > > Internet traffic, it > > >doesn't make sense. The median TCP session has <= 10 > > packets going each > > >way, and no concept of a rate, as there is only one > > actual data segment > > >each way. To try to set up call state as it exists in > > the telco world, and > > >make "per-call" guarantees, is to dramatically increase > > the message > > >traffic without materially changing much, and even to > > set up RSVP flow > > >state for such sessions is difficult as there is no > > concept of a rate - > > >and the guy requesting the rate has no concept of the > > amount of data he is > > >asking for. > > > > > > _______________________________________________ > > 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 From ieprep-admin@ietf.org Wed Apr 3 03:11:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26946 for ; Wed, 3 Apr 2002 03:11:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02583; Wed, 3 Apr 2002 03:07:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02537 for ; Wed, 3 Apr 2002 03:06:58 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26906 for ; Wed, 3 Apr 2002 03:06:50 -0500 (EST) Received: from host213-122-42-104.in-addr.btopenworld.com ([213.122.42.104] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16sfmU-0002K5-00; Wed, 03 Apr 2002 09:06:10 +0100 Message-ID: <3CAAB809.A1369B20@degree2.com> Date: Wed, 03 Apr 2002 09:06:33 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Marshall Eubanks , ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020402113306.05939df0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > Let's take Ken's comment yesterday, that multicast might be useful for VoIP > and video on IP for emergency workers. VoIP has certain requirements for > emergency workers, in the sense that if there is a choice between a VoIP > call that will help manage the emergency getting through and some other > call getting through, one wants the emergency-useful call to go through. > VoIP-for-emergency also has all the usual issues of VoIP - the QoS better > be there, by whatever means. > > Now, when we want to have a teleconference among various people at > disparate locations, we will want to use multicast routing to do that. But > the issues here are not for multicast per se, they are for the voice/video > application that happens to be in use, and they are the same issues as > apply to point to point calls. Group calls and press-to-talk are key emergency service applications supported by layer 3 multicast in professional land mobile services. Attempts to do it at layer 7 in circuit switched networks such as GSM have succeeded but are expensive in resources and erratic in availability. It is natural to use IP multicast to support these applications. Users will compromise on voice quality as long as they remain in contact and get something through. Best effort is not good enough in principle but will work up to a point. Some bandwidth has to guaranteed under congestion - I did some qualitative experiments which suggested I could tolerate about 10 Kbps per conversation. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 3 06:57:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00084 for ; Wed, 3 Apr 2002 06:57:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15563; Wed, 3 Apr 2002 06:49:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15534 for ; Wed, 3 Apr 2002 06:49:40 -0500 (EST) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29964 for ; Wed, 3 Apr 2002 06:49:37 -0500 (EST) Received: from degree2.com (kohoutek.degree2.com [172.30.40.31]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g33BnW306066; Wed, 3 Apr 2002 12:49:32 +0100 Message-ID: <3CAAEC74.9030106@degree2.com> Date: Wed, 03 Apr 2002 12:50:12 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org Subject: Re: [Ieprep] fine-grain QoS References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020402114443.030ffad8@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, Thanks for the AF tutorial. > > As it happens, in my (admittedly small but deliberately overloaded) > > voice/video network, I put signalling and call traffic (inc. in-band > > RSVP) in two EF aggregates (signalling given a higher quality > service) - > > I believe that putting it in AF3 runs the risk of losing it or > demoting > > it further. In conditions of heavy congestion anything in the lower > ranks > > of AF will suffer. > > Your comment leads me to believe that you are under the (unfortunately > common) misunderstanding that the classes of traffic are somehow > priorities, and that AF4 would therefore shove AF3 out of the way. Are > you > under this misunderstanding? That's not how rate-based policies work. > My "understanding", please question it, is that EF and AFn are distinguished by their forwarding behaviour. I don't see where priority comes in. It wouldn't be a useful discriminator in the congested situation especially, nor indeed anywhere, or at all in my experience - it is quality that is the discriminator, as I see I said above. Something has to give under congestion and putting things in EF gets them in and out as smartly as possible. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 3 10:26:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05955 for ; Wed, 3 Apr 2002 10:26:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01649; Wed, 3 Apr 2002 10:23:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01553 for ; Wed, 3 Apr 2002 10:23:33 -0500 (EST) Received: from mail.mazunetworks.com (mazu.mazunetworks.com [4.19.249.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05856 for ; Wed, 3 Apr 2002 10:23:30 -0500 (EST) Received: from volta.mazunetworks.com (IDENT:root@volta.mazunetworks.com [10.0.0.118]) by mail.mazunetworks.com (8.11.2/8.11.2) with ESMTP id g33FN3a13257; Wed, 3 Apr 2002 10:23:03 -0500 Received: from volta (dean@localhost) by volta.mazunetworks.com (8.11.0/8.11.0) with ESMTP id g33FMkG00954; Wed, 3 Apr 2002 10:22:46 -0500 Message-Id: <200204031522.g33FMkG00954@volta.mazunetworks.com> To: Alistair Munro cc: Fred Baker , Marshall Eubanks , ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast In-Reply-To: Message from Alistair Munro of "Wed, 03 Apr 2002 09:06:33 +0100." <3CAAB809.A1369B20@degree2.com> Date: Wed, 03 Apr 2002 10:22:45 -0500 From: Dean Bogdanovic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > Group calls and press-to-talk are key emergency service applications supporte > d by > layer 3 multicast in professional land mobile services. Attempts to do it at > layer > 7 in circuit switched networks such as GSM have succeeded but are expensive i > n > resources and erratic in availability. It is natural to use IP multicast to > support these applications. > > Users will compromise on voice quality as long as they remain in contact and > get > something through. Best effort is not good enough in principle but will work > up to > a point. Some bandwidth has to guaranteed under congestion - I did some > qualitative experiments which suggested I could tolerate about 10 Kbps per > conversation. I can agree with your statement that IP multicast is very efficient for key applications, but I am wondering on how much voice quality degradation users are willing to compromise, because voice quality in emergency situation is very important. Usually in emergency situations noise level is pretty high, so lower voice quality might lead to harder understanding between emergency workers. I do not know how did you calculated the 10kbps per conversation, because I do not know the other parameters. In voice packetization there are two key parameters: 1. voice compression 2. number of voice frames per 1 datagram This two parameters will give us the bandwidth requirements, but also will influence the voice quality. Here is an expample 1st voice call is using ADPCM24 codec and 2nd voice call is using G729a codec. ADPCM generates every 8 ms 1 voiceframe of 24 bytes. To that we have to add IP and UDP and RTP headers. If 4 voice frames are packetized in one datagram, each datagram is carrying 32ms of voice. G729a generates every 10 ms 1 voiceframe of 10 bytes. If 4 voiceframes are packetized, each packet is carrying 40 ms of voice. With adding more voiceframes per 1 datagram (to a certain number) the bandwidth requirements are going down, but the voice quality can be impacted depending on the network congestion and the packetloss. Also with increasing the voiceframes per 1 datagram the latency requirements are more elastic, but the packetloss will have a higher impact on the voice quality Also using header compression algorithms are inducing more latency to the process and there is a fixed latency bugdet. If the latency is bigger than the budget the voice queue is starved (because late packets are dropped from the voice queue). And the last one is voice quality perception. What you or me accept as OK, other people might not. I believe that bandwidth requirements for voice calls have to be better investigated. I like the idea of using IM as emergency service, because it has voice and data capabilities. One additional feature to IM, could be voice recognition sw. I believe that hearing and reading sent information can help in emergency situations. There are number of possibilities to offer various IM sessions types: 1.high quality voice conversation - real time requirements (PSTN like) 2.high quality voice conversation - non real time (like IM, messages are replayed after the whole data is delivered, this gives only simplex communications, but eases the requirement on the network, because data can be resend to a certain extent. Voice recognition sw can be used here for text output, which helps a lot in noise enviroments. How often emergency workers have to repeat informations over radio stations because of noise or bad reception) 3. text only etc. --br Dean _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 3 10:43:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06918 for ; Wed, 3 Apr 2002 10:43:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03630; Wed, 3 Apr 2002 10:40:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03595 for ; Wed, 3 Apr 2002 10:40:29 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06765 for ; Wed, 3 Apr 2002 10:40:26 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Apr 2002 16:40:13 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Dean Bogdanovic cc: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast In-reply-to: Your message of "Wed, 03 Apr 2002 10:22:45 CDT." <200204031522.g33FMkG00954@volta.mazunetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Apr 2002 16:40:11 +0100 Message-ID: <1269.1017848411@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > And the last one is voice quality perception. What you or me accept as > OK, other people might not. see the following for a couple of perspectives on user tolerance of loss/delay for VoIP traffic. http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip http://www.cs.ucl.ac.uk/staff/A.Sasse/inet95audio.ps the above does not provide a definitive answer, just some insights. and as previously stated, your mileage may very depending on the Codec in use. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 3 12:41:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10259 for ; Wed, 3 Apr 2002 12:41:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13800; Wed, 3 Apr 2002 12:40:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13733 for ; Wed, 3 Apr 2002 12:39:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10217 for ; Wed, 3 Apr 2002 12:39:54 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g33HdIX26352; Wed, 3 Apr 2002 09:39:18 -0800 (PST) Message-Id: <5.1.0.14.2.20020403081737.0585f208@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 09:22:23 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] fine-grain QoS Cc: ieprep@ietf.org In-Reply-To: <3CAAEC74.9030106@degree2.com> References: <5.1.0.14.2.20020331230050.0eb39ec8@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401111847.01ebcd78@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020401122408.01ea9a10@mira-sjcm-4.cisco.com> <5.1.0.14.2.20020402114443.030ffad8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 03:50 AM 4/3/2002, Alistair Munro wrote: >My "understanding", please question it, is that EF and AFn are >distinguished by their forwarding behaviour. I believe that this is wandering fairly far afield, but I'll try to answer the questions in the hopes that we can eventually get back to our chartered tasks. Since diffserv is a data plane technology, the only thing the can talk about is what happens to packets in flight. Is that what you mean by "forwarding behaviour"? > I don't see where priority comes in. Suppose you are at the airport trying to check in. There is a grand total of one person checking people in and taking their baggage, at your favorite airline, but there are two lines - the first class line and the line everyone else is in. The clerk operates on the rule that "if anyone is in the first class line, serve them, and only serve 'everyone else' if there is nobody in the first class line". The clerk is acting as a 'scheduler', and the lines are (obviously) 'queues'. The rule by which the clerk operates is called a 'scheduling discipline'. This particular scheduling discipline is called 'priority': the first class line experiences relatively little delay, and relatively little variation in delay, because the clerk is taking them first. All of that delay is transferred to "everyone else". Now, let's make life more difficult for our overworked clerk. "Everyone else" is divided into four lines in some fashion, perhaps by the color of shirt they are wearing that day. You said yesterday that you were concerned that AF3 would get overwhelmed by AF4, since AF4 is a busy class. This would be analogous to telling the clerk "take anyone in first class, and absent that, take from general access line 4,, and failing that take from general line 3, and so on." This scheduling discipline is a generalization of priority with multiple levels of priority. As you say, if we follow a priority discipline, and one line is taken before another, eventually something "has to give", and it might well be the people in the lowest priority line. But suppose instead that the four lines that "everyone else" is located in get some form of round robin discipline. The clerk is told: "spend one minute serving people from line 1, then spend five minutes serving people from line 2, then spend two minutes serving people from line 3, then spend eight minutes serving people from line 4. If at any time someone shows up in the first class line, take them next, but do not account the time spent serving them against whatever line you happen to be serving; when you can, return to that line and keep going. If the line you are operating on goes empty, do not take a break; instead, start the time for the next line." That is clearly a little more complex. What we have is four rate-based queues, with different 'weights', and the scheduling discipline is a variation on one called 'weighted round robin'. What's going to happen? Well, suppose that people are arriving at line 4 at approximately the rate it is being served. What is going to happen to them is that they may wait a while in queue, but they will in fact get served. If people are arriving at line 2 far more rapidly than it is being served, people will eventually decide that the wait isn't worth it, and go do something else. They will be "dropped". If people are arriving at line 1 - which has very little resources allocated to it - significantly less rapidly than it is being served, they will often walk up to an empty line, wait a few minutes for the line's turn, and then get served. Of course, the first class line is still getting excellent service. What I have just described is one way to implement EF and AF in a router scheduler; there are other, more complex, algorithms for dealing with the AF classes. But the effect is similar - each queue gets a service rate, and the delay and drop characteristics are largely independent of the other queues - it depends mostly on the arrival and departure rate of elements in the queue you are worried about. >Something has to give under congestion and putting things in EF gets them >in and out as smartly as possible. yes, and for traffic that has that requirement - voice - that is the right thing to do. Elastic traffic (of which TCP-based internet applications are examples) doesn't have an "as little jitter as we can manage" requirement; that's part of the meaning of the word 'elastic". It does have a requirement for a certain average rate of service, but that rate can be very low, on the order of seconds to tens of seconds between events. What it *does* require is that whatever rate it gets it gets fairly consistently. The fact that instant messaging worked on 9/11 is evidence that this works quite well under load. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 3 13:00:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10871 for ; Wed, 3 Apr 2002 13:00:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13767; Wed, 3 Apr 2002 12:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13724 for ; Wed, 3 Apr 2002 12:39:55 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10215 for ; Wed, 3 Apr 2002 12:39:53 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g33HdJX26361; Wed, 3 Apr 2002 09:39:19 -0800 (PST) Message-Id: <5.1.0.14.2.20020403092306.021314b0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Apr 2002 09:26:17 -0800 To: Dean Bogdanovic From: Fred Baker Subject: Re: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org In-Reply-To: <200204031522.g33FMkG00954@volta.mazunetworks.com> References: <3CAAB809.A1369B20@degree2.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 07:22 AM 4/3/2002, Dean Bogdanovic wrote: >I believe that bandwidth requirements for voice calls have to be >better investigated. Like you, I have a hard time imagining why voice calls in emergency situations are significantly different than voice calls any other time. We have spent the past decade making voice work well in Internet technology; what we want to discuss here is how to use the technology, not how to engineer it. Hence my comments about engineering it using multicast. Certainly one can do that, but multicast doesn't impose requirements on us, it is a way to meet the requirements. I would really like to get back to the chartered work of this working group, which is describing requirements and making recommendations for emergency use of internet technology. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 02:11:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05818 for ; Thu, 4 Apr 2002 02:11:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08810; Thu, 4 Apr 2002 02:04:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08773 for ; Thu, 4 Apr 2002 02:04:16 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02947 for ; Thu, 4 Apr 2002 02:04:13 -0500 (EST) Received: from [4.19.79.84] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1332787; Thu, 04 Apr 2002 02:04:14 -0500 From: "Marshall Eubanks" Subject: Re: [Ieprep] Public Safety? To: "James M. Polk" , Marshall Eubanks Cc: "Nguyen, An" , ieprep@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Thu, 04 Apr 2002 02:04:14 -0500 Message-ID: In-Reply-To: <4.1.20020402140932.033247a0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Tue, 02 Apr 2002 14:18:52 -0600 "James M. Polk" wrote: > > At 03:42 PM 4/1/2002 -0500, Marshall Eubanks wrote: > >TESLA > > > Good point. I will raise this in msec. Marshall >http://www.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt > > This will, in our case, call for a *single CA level* with > a *single* root key > for all emergency related agencies in order to > intercommunicate (local > police/Sheriff, State police, Fire, hospitals, private > ambulance companies, > FEMA, Red Cross, FBI, INS, Border Patrol, National Guard > and then maybe the > DOD).... unless I just misread this ID. That might be > doable, and might be > recommended as an output of this group -- but I don't > believe that can become > international in requirements/recommendations from this > group and hope to see > it happen in our lifetimes > > I could be wrong though.... > > > ************************************* > "People generally demand more respect for their own > rights than they are > willing to allow for others" > > James M. Polk > Consulting Engineer > Office of the CTO > > Cisco Systems > 2200 East President George Bush Turnpike > Richardson, TX 75082 USA > w) 972.813.5208 > f) 972.813.5280 > www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 04:13:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07411 for ; Thu, 4 Apr 2002 04:13:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14562; Thu, 4 Apr 2002 03:52:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14528 for ; Thu, 4 Apr 2002 03:52:15 -0500 (EST) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07168 for ; Thu, 4 Apr 2002 03:51:58 -0500 (EST) Received: from host213-123-49-145.btinternet.com ([213.123.49.145] helo=degree2.com) by tungsten.btinternet.com with esmtp (Exim 3.22 #8) id 16t2yB-0001rn-00; Thu, 04 Apr 2002 09:51:47 +0100 Message-ID: <3CAC1448.8E7879F8@degree2.com> Date: Thu, 04 Apr 2002 09:52:24 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Dean Bogdanovic , ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <3CAAB809.A1369B20@degree2.com> <5.1.0.14.2.20020403092306.021314b0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, > Like you, I have a hard time imagining why voice calls in emergency > situations are significantly different than voice calls any other time. I am following the charter, I think, in trying to identify current (best) practice. The remarks were intended to provide information on that. Specifically: 1. On diferences in expectation of quality, I speak only from experience, input received from PMR users and equipment vendors, and listening tests with around 500 subjects using recorded data from the UK MPT1327 system. 2. The 10 Kbps claim is not calculated but based on listening tests using a standard H.323 VoIP handset, G.711 codec, EF forwarding (roughly) with a delay across the network element of about 74 usec per byte, offered load about 200% of the element's forwarding capacity. I was not able to measure the loss at the phones if any - most frames were discarded by the network element. The 10 Kbps is not representative of the technology that emergency services use but speech was intelligible. 3. Typical PMR codecs run in 6.25 Kbps - there is a significant difference in the delivered service from the one Joe Public would get when he makes a 911 call from his cellphone/PDA/whatever. The observation was intended to be a response to Fred's remark that quality is essential - yes, it is but knowing more about current practice will affect the constraints on the protocols that we specify for the congested situation. I wouldn't want to specify codecs, but as we are providing information about deployment issues, we ought to draw attention to current practice and effects of loss and delay. As Dean noted, I think, this is a complex topic. > I would really like to get back to the chartered work of this working > group, which is describing requirements and making recommendations for > emergency use of internet technology. I see multicast as an essential part of the solution. Current practice for using multicast in interactive real-time applications is a mystery to me. I do not think that oversubscription of the multicast address space will ever be an issue. Scalability and reliability requirements may point us to specific multicast protocols. I have no idea about routing. Are we going to write applicability statements (although not currently in the charter as far as I can tell)? If we are, then these discussion seem to me to indicate non-requirements quite well. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 04:48:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08225 for ; Thu, 4 Apr 2002 04:48:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17434; Thu, 4 Apr 2002 04:47:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17396 for ; Thu, 4 Apr 2002 04:47:04 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08173 for ; Thu, 4 Apr 2002 04:46:59 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 4 Apr 2002 10:50:12 +0100 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id GAA25729 for ; Thu, 4 Apr 2002 06:47:43 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 10:40:17 +0100 Message-ID: From: "Gibson, Mark" To: ieprep@ietf.org Subject: RE: [Ieprep] a little homily - benefits of multicast Date: Thu, 4 Apr 2002 10:40:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org You might also wish to cast you eyes over the appendix section of the referenced and now expired draft. While more global in scope, it captures the issues nicely. http://alternic.net/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.txt Mark meant to send this to the list, sorry you got two copies Ken :( -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: 03 April 2002 16:40 To: Dean Bogdanovic Cc: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast > And the last one is voice quality perception. What you or me accept as > OK, other people might not. see the following for a couple of perspectives on user tolerance of loss/delay for VoIP traffic. http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip http://www.cs.ucl.ac.uk/staff/A.Sasse/inet95audio.ps the above does not provide a definitive answer, just some insights. and as previously stated, your mileage may very depending on the Codec in use. -ken _______________________________________________ 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 From ieprep-admin@ietf.org Thu Apr 4 08:31:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13452 for ; Thu, 4 Apr 2002 08:31:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29701; Thu, 4 Apr 2002 08:30:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29649 for ; Thu, 4 Apr 2002 08:30:44 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13368 for ; Thu, 4 Apr 2002 08:30:41 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g34DUha14228 for ieprep@ietf.org; Thu, 4 Apr 2002 08:30:43 -0500 (EST) Date: Thu, 4 Apr 2002 08:30:43 -0500 (EST) From: Scott Bradner Message-Id: <200204041330.g34DUha14228@newdev.harvard.edu> To: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org it seems to me that these two sentences are mutually exclusive > I see multicast as an essential part of the solution. Current practice for > using multicast in interactive real-time applications is a mystery to me. we have no "running code" that multicast has any real use in the Internet - if that is the case then how can multicast be "an essential part of the solution" scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 08:45:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13990 for ; Thu, 4 Apr 2002 08:45:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00476; Thu, 4 Apr 2002 08:42:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00441 for ; Thu, 4 Apr 2002 08:42:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13895 for ; Thu, 4 Apr 2002 08:41:58 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA22618; Thu, 4 Apr 2002 08:41:52 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-41-36.mad.east.verizon.net [138.89.41.36]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g34DfoPm022924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Apr 2002 08:41:51 -0500 (EST) Message-ID: <3CAC581E.CC16A6B4@cs.columbia.edu> Date: Thu, 04 Apr 2002 08:41:50 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alistair Munro CC: Fred Baker , "Gunn, Janet NE" , ieprep@ietf.org Subject: Re: [Ieprep] Public Safety? physical location References: <5.1.0.14.2.20020328211333.020c6c18@mira-sjcm-4.cisco.com> <3CAC563E.9615418B@degree2.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > > There are a number of issues in physical location. One, it tends to imply > > the use of a GPS or something like it. > > There are terminal based solutions (e.g. GPS) and network based ones (DOA, > etc.). I don't think the technology matters. It is the protocol that delivers > it that we should identify - has the positioining group got this far. > > > Another issue is related to privacy. If I am calling 911 to report an > > accident, I most certainly want the 911 operator to know where I am. > > I think the FCC wants this too... privacy is not an issue. You might want to join the discussion in geopriv. It's been treading water for two+ years. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 08:47:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14066 for ; Thu, 4 Apr 2002 08:47:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00169; Thu, 4 Apr 2002 08:33:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00137 for ; Thu, 4 Apr 2002 08:33:41 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13556 for ; Thu, 4 Apr 2002 08:33:30 -0500 (EST) Received: from host213-1-182-127.btinternet.com ([213.1.182.127] helo=degree2.com) by gadolinium.btinternet.com with esmtp (Exim 3.22 #8) id 16t7MZ-0006SK-00; Thu, 04 Apr 2002 14:33:15 +0100 Message-ID: <3CAC563E.9615418B@degree2.com> Date: Thu, 04 Apr 2002 14:33:51 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: "Gunn, Janet NE" , ieprep@ietf.org Subject: Re: [Ieprep] Public Safety? physical location References: <5.1.0.14.2.20020328211333.020c6c18@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, Please correct me if the following were beaten to death already - I couldn't find anything explicit in the follow-ups. > I believe that there is a working group addressing physical location; if it > is a requirement, the obvious thing for us to do is state and support the > requirement, and let said working group work out the details. > Positioning information *is* a requirement, more advanced in the US but probably coming in Europe too. > There are a number of issues in physical location. One, it tends to imply > the use of a GPS or something like it. There are terminal based solutions (e.g. GPS) and network based ones (DOA, etc.). I don't think the technology matters. It is the protocol that delivers it that we should identify - has the positioining group got this far. > Another issue is related to privacy. If I am calling 911 to report an > accident, I most certainly want the 911 operator to know where I am. I think the FCC wants this too... privacy is not an issue. > >If public safety is in scope, land mobile radio interoperability (again, > >specifically out of scope for GETS) is an important requirement. During > >the recovery efforts after 9/11, the the lack of interoperability between > >the land mobile radio networks used by the various groups (Police, Fire, > >Rescue, etc) from different jurisdictions was a major problem. It seems > >plausible that, if each of these systems had an interface to the Internet, > >the Internet could provide the interoperability between the systems. We should take care to solve the right problem. The different sevices are often reluctant to work together, claiming inidividual unique requirements even while using the same equipment - a political problem. Sometimes they prevent each other working together due to incompatible spectrum allocations and modulation schemes that generate disruptive interference - also a political problem which has some funds being thrown at it by Mr. Bush. It's a nice thought, but APCO has made very little progress in encouraging the necessary will to cooperate. I don't think we have a technology to offer to solve that problem. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 08:50:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14205 for ; Thu, 4 Apr 2002 08:50:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00258; Thu, 4 Apr 2002 08:35:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00226 for ; Thu, 4 Apr 2002 08:35:37 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13610 for ; Thu, 4 Apr 2002 08:35:34 -0500 (EST) Received: from host213-1-182-127.btinternet.com ([213.1.182.127] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16t7OF-0003Tq-00; Thu, 04 Apr 2002 14:34:59 +0100 Message-ID: <3CAC569A.5BF6323B@degree2.com> Date: Thu, 04 Apr 2002 14:35:22 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Bogdanovic CC: Fred Baker , Marshall Eubanks , ieprep@ietf.org References: <200204031522.g33FMkG00954@volta.mazunetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] Codecs, VoIP and IM Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Dean, > I believe that bandwidth requirements for voice calls have to be > better investigated. As a general comment, codecs used in professional systems require less bandwidth (6.25 Kbps for example); some GSM codecs go lower. I believe the driver for this is to squeeze as many calls as possible into what is often very limited overall bandwidth. If we are going to use IP on these platforms, which seems to me to be a good idea, then the current emergency service practices must be explained and compared with practices used in deployment of fixed network IP voice solutions. > I like the idea of using IM as emergency service, because it has voice > and data capabilities. One additional feature to IM, could be voice > recognition sw. I believe that hearing and reading sent information > can help in emergency situations. Messaging services for downloading pictures, fingerprints, audio-clips, etc., etc. have been used for over 15 years, so IM seems a good candidate as a solution to support this application. However instant means INSTANT. I am not aware of applications based on two-way IM-like services. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 08:55:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14368 for ; Thu, 4 Apr 2002 08:55:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01188; Thu, 4 Apr 2002 08:52:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01160 for ; Thu, 4 Apr 2002 08:52:11 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14244 for ; Thu, 4 Apr 2002 08:52:07 -0500 (EST) Received: from host213-122-138-215.in-addr.btopenworld.com ([213.122.138.215] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16t7ep-0004tj-00; Thu, 04 Apr 2002 14:52:08 +0100 Message-ID: <3CAC5AAE.812F6833@degree2.com> Date: Thu, 04 Apr 2002 14:52:46 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Bradner CC: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <200204041330.g34DUha14228@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Scott, > it seems to me that these two sentences are mutually exclusive > > > I see multicast as an essential part of the solution. Current practice for > > using multicast in interactive real-time applications is a mystery to me. > > we have no "running code" that multicast has any real use in the Internet - I can't quite parse this, so excuse any misunderstanding. There are conferencing applications based on multicast that I have used, and I am sure that you have too. On the non-interactive side, there is content being distributed from Internet2 sites using multicast - albeit experimental. Microsoft media server distributes content using multicast. What running code are you looking for specifically - have I missed your point? However my point was that I don't know what to refer to concerning best practice on how to do conferencing using IP multicast. > if that is the case then how can multicast be "an essential part of the > solution" Layer 2 and layer 3 multicast is widely used in emergency/professional mobile systems for several applications. I mentioned group calls and there are others. Users of those systems would insist on having these applications on an Internet platform. Whether these applications would use IP layer 3 multicast is a reasonable question to ask. They could be implemented on some platforms using the layer 2 capability (e.g. TETRA) but not, for example, in a GSM network. 802.11 is something else again. What you would you propose as an alternative to multicast? Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 09:12:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15151 for ; Thu, 4 Apr 2002 09:12:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02813; Thu, 4 Apr 2002 09:08:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02777 for ; Thu, 4 Apr 2002 09:08:49 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14945 for ; Thu, 4 Apr 2002 09:08:45 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Apr 2002 15:08:43 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Alistair Munro cc: ieprep@ietf.org Subject: Re: [Ieprep] Codecs, VoIP and IM In-reply-to: Your message of "Thu, 04 Apr 2002 14:35:22 BST." <3CAC569A.5BF6323B@degree2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 15:08:43 +0100 Message-ID: <1316.1017929323@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org hi, > As a general comment, codecs used in professional systems require less > bandwidth (6.25 Kbps for example); some GSM codecs go lower. I believe > the driver for this is to squeeze as many calls as possible into what is > often very limited overall bandwidth. If we are going to use IP on these > platforms, which seems to me to be a good idea, then the current > emergency service practices must be explained and compared with practices > used in deployment of fixed network IP voice solutions. could you elaborate and be more specific by what you mean by the term "current emergency service practices"? > Messaging services for downloading pictures, fingerprints, audio-clips, > etc., etc. have been used for over 15 years, so IM seems a good candidate > as a solution to support this application. However instant means INSTANT. perhaps it depends on how you define "INSTANT". the end-to-end delay of IM text messages via propagation and/or retransmission delay are not as stringent as that expected of interactive voice. so if it takes in the order of seconds to send a line of text for IM, thats fine, and that why folks have a habit of chiming in saying "use IM, problem solved :-)". i don't mean to imply that is what you're saying, but simply that IM (at least in text form) is a type of elastic application that can tolerate relatively high levels of loss and delay and yet still operate well enough for a user. > I am not aware of applications based on two-way IM-like services. whats a "two-way" IM-like service? we have had unix "talk" for a loooong time. the IM craze simply made the presence of others a bit easier to figure out. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 09:23:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15527 for ; Thu, 4 Apr 2002 09:23:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03652; Thu, 4 Apr 2002 09:23:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03618 for ; Thu, 4 Apr 2002 09:23:17 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15524 for ; Thu, 4 Apr 2002 09:23:12 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g34ENCw14489; Thu, 4 Apr 2002 09:23:12 -0500 (EST) Date: Thu, 4 Apr 2002 09:23:12 -0500 (EST) From: Scott Bradner Message-Id: <200204041423.g34ENCw14489@newdev.harvard.edu> To: alistair.munro@degree2.com, sob@harvard.edu Subject: Re: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > I can't quite parse this, so excuse any misunderstanding. There are > conferencing applications based on multicast that I have used, and I > am sure that you have too. I know of no widely deployed, well used, multicast service on the Internet. There are a number of LAN or enterprise-level multicast applications but not ISP-based ones that have had enough use to show that they can be made to work operationally > What you would you propose as an alternative to multicast? I propose that we, in this group, not invent new applications but instead figure out how to ensure that existing applications work in times of emergency. And I think that doing anything with multicast would be inventing new applications. That does not mean that people in the IETF should not work on multicast. The SSM WG is doing just that. But until we have evidence that multicast services can and are deployed in ISPs we do not have any idea what problems to solve in the case of emergency. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 11:55:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22491 for ; Thu, 4 Apr 2002 11:55:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14368; Thu, 4 Apr 2002 11:52:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14338 for ; Thu, 4 Apr 2002 11:52:55 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22399 for ; Thu, 4 Apr 2002 11:52:51 -0500 (EST) Received: from in-addr.btopenworld.com ([62.6.75.85] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16tATh-0000ec-00; Thu, 04 Apr 2002 17:52:50 +0100 Message-ID: <3CAC8509.CA847C0E@degree2.com> Date: Thu, 04 Apr 2002 17:53:29 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org Subject: Re: [Ieprep] Codecs, VoIP and IM References: <1316.1017929323@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ken, > > As a general comment, codecs used in professional systems require less > > bandwidth (6.25 Kbps for example); some GSM codecs go lower. I believe > > the driver for this is to squeeze as many calls as possible into what is > > often very limited overall bandwidth. If we are going to use IP on these > > platforms, which seems to me to be a good idea, then the current > > emergency service practices must be explained and compared with practices > > used in deployment of fixed network IP voice solutions. > > could you elaborate and be more specific by what you mean by the term > "current emergency service practices"? > I meant the specific codecs, sampling rate and sample sizes, toleable error rates, etc. Why? To give guidelines on deployment and possible bandwidth allocations. I don't care waht they use but we should be able to say what *not* to do if the applications are going to work. > > Messaging services for downloading pictures, fingerprints, audio-clips, > > etc., etc. have been used for over 15 years, so IM seems a good candidate > > as a solution to support this application. However instant means INSTANT. > > perhaps it depends on how you define "INSTANT". the end-to-end delay of > IM text messages via propagation and/or retransmission delay are not as > stringent as that expected of interactive voice. so if it takes in the > order of seconds to send a line of text for IM, thats fine, and that > why folks have a habit of chiming in saying "use IM, problem solved :-)". > i don't mean to imply that is what you're saying, but simply that IM > (at least in text form) is a type of elastic application that can tolerate > relatively high levels of loss and delay and yet still operate well enough > for a user. A few 10s of seconds for a picture at reasonable resolution of a key person/suspect - finger in the air here I'm afraid. > > I am not aware of applications based on two-way IM-like services. > > whats a "two-way" IM-like service? we have had unix "talk" for a loooong > time. the IM craze simply made the presence of others a bit easier to > figure out. I referred to a comment from Dean, I think, who mentioned the possibility of holding a voice conversation using IM. I think this is a bit on the edge and may well not solve a problem for anybody. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 12:56:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28327 for ; Thu, 4 Apr 2002 12:56:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19911; Thu, 4 Apr 2002 12:51:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19884 for ; Thu, 4 Apr 2002 12:51:36 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28135 for ; Thu, 4 Apr 2002 12:51:34 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g34HpZs15942; Thu, 4 Apr 2002 12:51:35 -0500 (EST) Date: Thu, 4 Apr 2002 12:51:35 -0500 (EST) From: Scott Bradner Message-Id: <200204041751.g34HpZs15942@newdev.harvard.edu> To: alistair.munro@degree2.com, sob@harvard.edu Subject: Re: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > I don't see why innovators can't be left to implement new applications for > closed emergency service networks, using multicast or not. I fully support this - I just do not think that things are ready for this working group to make any statements about the use of multicast (or to ask for an allocation of multicast addresses) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 12:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28427 for ; Thu, 4 Apr 2002 12:58:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19695; Thu, 4 Apr 2002 12:48:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19658 for ; Thu, 4 Apr 2002 12:48:45 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26178 for ; Thu, 4 Apr 2002 12:48:36 -0500 (EST) Received: from host213-122-118-230.in-addr.btopenworld.com ([213.122.118.230] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16tBLb-0006i2-00; Thu, 04 Apr 2002 18:48:32 +0100 Message-ID: <3CAC9216.DF74E44A@degree2.com> Date: Thu, 04 Apr 2002 18:49:10 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Bradner CC: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <200204041423.g34ENCw14489@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Scott, Thanks for the clarification. > I know of no widely deployed, well used, multicast service on the Internet. > There are a number of LAN or enterprise-level multicast applications but > not ISP-based ones that have had enough use to show that they can be > made to work operationally Yes, that was my feeling too. A set of applications running on IP for the purpose of supporting the emergency services operationally within a closed network would fall in the category of enterprise, possibly, and might have more success. I think we would have to say do *not* use multicast to implement emergency services if you are a commodity ISP. > > What you would you propose as an alternative to multicast? > > I propose that we, in this group, not invent new applications but instead > figure out how to ensure that existing applications work in times of > emergency. I would limit the applicability of this to commodity ISPs. Possibly something along the lines of: must turn on DiffServ (RFCs xxxx apply) take heed of RFC IntServ in DiffServ environment (sorry about choice of words) indicative bandwidth allocations I don't see why innovators can't be left to implement new applications for closed emergency service networks, using multicast or not. I have been working on specifying this sort of thing with SIP, mobility, and multicast - and it is hard work... but there are applications out there. I'm sure we could write some sort of best practice advice. > And I think that doing anything with multicast would be > inventing new applications. If the functionality we *think* is needed already exists, can we not draw attention to it and its use as part of current practice? Without specifying applications? > But until we have evidence that multicast services can [be] and are > deployed in ISPs we do not have any idea what problems to solve in the case > of emergency. Before I came across this WG, I had a fairly simple-minded view of what an ISP offering Internet services over a 3G commodity mobile network would have to do to support services in an emergency and emergency services for the public and professionals. From earlier analysis, we believed that multicast is apropriate for special professional purposes. If you are saying that there are no ISP supported multicast services that must be maintained in an emergency then I agree, but I do not agree that multicast should not be used for certain purposes - just surrounded by skull-and-crossbones for the unwary. I will have to go back to the Baker and Folts drafts to see what I think the wording should be. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 13:14:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29265 for ; Thu, 4 Apr 2002 13:14:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21130; Thu, 4 Apr 2002 13:05:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21101 for ; Thu, 4 Apr 2002 13:05:09 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28623 for ; Thu, 4 Apr 2002 13:05:02 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50FPSH>; Thu, 4 Apr 2002 13:04:18 -0500 Message-ID: From: "Folts, Harold" To: "'James M. Polk'" , ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority Date: Thu, 4 Apr 2002 13:04:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC03.2076BE30" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC03.2076BE30 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, March 25, 2002 1:24 PM To: ieprep@ietf.org Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: Ken, I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS. I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses) [HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure. Hal ------_=_NextPart_001_01C1DC03.2076BE30 Content-Type: text/html; charset="iso-8859-1"
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, March 25, 2002 1:24 PM
To: ieprep@ietf.org
Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority

At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote:
Ken,

I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS.

I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses)


[HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure.
 
Hal 
------_=_NextPart_001_01C1DC03.2076BE30-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 13:29:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02921 for ; Thu, 4 Apr 2002 13:29:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22272; Thu, 4 Apr 2002 13:28:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22222 for ; Thu, 4 Apr 2002 13:28:51 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02768 for ; Thu, 4 Apr 2002 13:28:48 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34IS7qF024307; Thu, 4 Apr 2002 10:28:09 -0800 (PST) Message-Id: <5.1.0.14.2.20020404094654.0d926008@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 09:48:23 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] a little homily - benefits of multicast Cc: Dean Bogdanovic , ieprep@ietf.org In-Reply-To: <3CAC1448.8E7879F8@degree2.com> References: <3CAAB809.A1369B20@degree2.com> <5.1.0.14.2.20020403092306.021314b0@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:52 AM 4/4/2002, Alistair Munro wrote: >Are we going to write applicability statements (although not currently in the >charter as far as I can tell)? If we are, then these discussion seem to me to >indicate non-requirements quite well. for the moment, let's restrict ourselves to the charter. If we have specific requirements of voice, including that it (a) be understandable and (b) that it be possible to set up teleconferences of a certain size, that sounds like requirements. Let's leave the solutions to those problems to the groups working on those problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 13:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04102 for ; Thu, 4 Apr 2002 13:56:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24288; Thu, 4 Apr 2002 13:55:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24256 for ; Thu, 4 Apr 2002 13:55:26 -0500 (EST) Received: from chntex01.is.dyncorp.com (chntex01.is.dyncorp.com [131.131.133.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04088 for ; Thu, 4 Apr 2002 13:55:20 -0500 (EST) Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 13:53:30 -0500 Message-ID: From: "Gunn, Janet NE" To: "'Fred Baker'" , Alistair Munro Cc: ieprep@ietf.org Subject: Scope questions was RE: [Ieprep] a little homily - benefits of mu lticast Date: Thu, 4 Apr 2002 13:54:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC0A.26BA45D0" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC0A.26BA45D0 Content-Type: text/plain; charset="iso-8859-1" Something is not clear to me from the charter. Is the scope of this group restricted to the "public" or "core" Internet, or does it include entrerprize based "private" IP based networks? Janet -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, April 04, 2002 12:55 PM At 05:52 AM 4/4/2002, Alistair Munro wrote: >I can't quite parse this, so excuse any misunderstanding. There are >conferencing >applications based on multicast that I have used, and I am sure that you have >too. On the non-interactive side, there is content being distributed from >Internet2 sites using multicast - albeit experimental. Microsoft media server >distributes content using multicast. yes, and those are used in some enterprise environments. Scott is pointing out that there isn't much of this on the backbone. We know that there isn't, because few of the backbone operators enable multicast routing. They have had trouble with it and because they have not been able to obtain revenue from it, so the capability simply doesn't exist in their networks. Intersite multicast across the Internet mostly happens in tunnels. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep ------_=_NextPart_001_01C1DC0A.26BA45D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scope questions was RE: [Ieprep] a little homily - benefits of = multicast

Something is not clear to me from the charter.  = Is the scope of this group restricted to the "public" or = "core" Internet, or does it include entrerprize based = "private" IP based networks?

Janet

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, April 04, 2002 12:55 PM
At 05:52 AM 4/4/2002, Alistair Munro wrote:
>I can't quite parse this, so excuse any = misunderstanding. There are
>conferencing
>applications based on multicast that I have = used, and I am sure that you have
>too. On the non-interactive side, there is = content being distributed from
>Internet2 sites using multicast - albeit = experimental. Microsoft media server
>distributes content using multicast.

yes, and those are used in some enterprise = environments. Scott is pointing
out that there isn't much of this on the backbone. = We know that there
isn't, because few of the backbone operators enable = multicast routing. They
have had trouble with it and because they have not = been able to obtain
revenue from it, so the capability simply doesn't = exist in their networks.
Intersite multicast across the Internet mostly = happens in tunnels.


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

------_=_NextPart_001_01C1DC0A.26BA45D0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 14:05:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04371 for ; Thu, 4 Apr 2002 14:05:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22301; Thu, 4 Apr 2002 13:28:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22228 for ; Thu, 4 Apr 2002 13:28:51 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02770 for ; Thu, 4 Apr 2002 13:28:49 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34IS7qJ024307; Thu, 4 Apr 2002 10:28:14 -0800 (PST) Message-Id: <5.1.0.14.2.20020404095210.0d8d1390@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 09:54:45 -0800 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org In-Reply-To: <3CAC5AAE.812F6833@degree2.com> References: <200204041330.g34DUha14228@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 05:52 AM 4/4/2002, Alistair Munro wrote: >I can't quite parse this, so excuse any misunderstanding. There are >conferencing >applications based on multicast that I have used, and I am sure that you have >too. On the non-interactive side, there is content being distributed from >Internet2 sites using multicast - albeit experimental. Microsoft media server >distributes content using multicast. yes, and those are used in some enterprise environments. Scott is pointing out that there isn't much of this on the backbone. We know that there isn't, because few of the backbone operators enable multicast routing. They have had trouble with it and because they have not been able to obtain revenue from it, so the capability simply doesn't exist in their networks. Intersite multicast across the Internet mostly happens in tunnels. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 14:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04968 for ; Thu, 4 Apr 2002 14:19:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25610; Thu, 4 Apr 2002 14:15:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25574 for ; Thu, 4 Apr 2002 14:15:18 -0500 (EST) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04724 for ; Thu, 4 Apr 2002 14:15:11 -0500 (EST) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id MAA02880 for ; Thu, 4 Apr 2002 12:13:16 -0700 (MST) Received: from mknaomi ([130.131.166.58]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with SMTP id AAA1C96 for ; Thu, 4 Apr 2002 12:15:11 -0700 Received: FROM agcs.com BY mknaomi ; Thu Apr 04 12:15:11 2002 -0700 Message-ID: <3CACA63C.F35567BC@agcs.com> Date: Thu, 04 Apr 2002 12:15:08 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn, Janet NE" CC: "'Fred Baker'" , Alistair Munro , ieprep@ietf.org Subject: Re: Scope questions was RE: [Ieprep] a little homily - benefits of multicast References: Content-Type: multipart/mixed; boundary="------------C31A6952C32493C55C27E833" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. --------------C31A6952C32493C55C27E833 Content-Type: multipart/alternative; boundary="------------D5A28E095CC23AAFBFD869CB" --------------D5A28E095CC23AAFBFD869CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Janet, Good question. I would have thought it would have covered both. I join you in waiting for a more definitive response. "Gunn, Janet NE" wrote: > > > Something is not clear to me from the charter. Is the scope of this > group restricted to the "public" or "core" Internet, or does it > include entrerprize based "private" IP based networks? > > Janet > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, April 04, 2002 12:55 PM > At 05:52 AM 4/4/2002, Alistair Munro wrote: > >I can't quite parse this, so excuse any misunderstanding. There are > >conferencing > >applications based on multicast that I have used, and I am sure that > you have > >too. On the non-interactive side, there is content being distributed > from > >Internet2 sites using multicast - albeit experimental. Microsoft > media server > >distributes content using multicast. > > yes, and those are used in some enterprise environments. Scott is > pointing > out that there isn't much of this on the backbone. We know that there > isn't, because few of the backbone operators enable multicast routing. > They > have had trouble with it and because they have not been able to obtain > > revenue from it, so the capability simply doesn't exist in their > networks. > Intersite multicast across the Internet mostly happens in tunnels. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------D5A28E095CC23AAFBFD869CB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Janet,

Good question. I would have thought it would have covered both.

I join you in waiting for a more definitive response.

"Gunn, Janet NE" wrote:

 

Something is not clear to me from the charter.  Is the scope of this group restricted to the "public" or "core" Internet, or does it include entrerprize based "private" IP based networks?

Janet

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, April 04, 2002 12:55 PM
At 05:52 AM 4/4/2002, Alistair Munro wrote:
>I can't quite parse this, so excuse any misunderstanding. There are
>conferencing
>applications based on multicast that I have used, and I am sure that you have
>too. On the non-interactive side, there is content being distributed from
>Internet2 sites using multicast - albeit experimental. Microsoft media server
>distributes content using multicast.

yes, and those are used in some enterprise environments. Scott is pointing
out that there isn't much of this on the backbone. We know that there
isn't, because few of the backbone operators enable multicast routing. They
have had trouble with it and because they have not been able to obtain
revenue from it, so the capability simply doesn't exist in their networks.
Intersite multicast across the Internet mostly happens in tunnels.

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

--------------D5A28E095CC23AAFBFD869CB-- --------------C31A6952C32493C55C27E833 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org: adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;23888 fn:Stuart Goldman end:vcard --------------C31A6952C32493C55C27E833-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 14:30:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05678 for ; Thu, 4 Apr 2002 14:30:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26160; Thu, 4 Apr 2002 14:26:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26108 for ; Thu, 4 Apr 2002 14:26:00 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05261 for ; Thu, 4 Apr 2002 14:25:57 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Apr 2002 20:25:41 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org Subject: Re: Scope questions was RE: [Ieprep] a little homily - benefits o f mu lticast In-reply-to: Your message of "Thu, 04 Apr 2002 14:07:29 CDT." <313680C9A886D511A06000204840E1CF57CDD3@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 04 Apr 2002 20:25:41 +0100 Message-ID: <15393.1017948341@cs.ucl.ac.uk> From: Ken Carlberg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA26109 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > From: "Rosen, Brian" > > It would be interesting, for example, to be able to authenticate as an > emergency request, and have a firewall alter its policies for you.  ahhh, a nice lead in to the fun world of security.... ...at this time i'd like to ask (plead :-) if folks could take a look at and provide some feedback. admittedly, the draft is aimed at complimenting the Framework document, but we'd be very interested to get some comments from others -- is something missing?, is something broken?,is the draft on track and reasonable?, etc. I believe Fred has expressed an interest in making the draft a working group item, but there is a strong desire to get some feedback on the list about it as well. thanks, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 14:49:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06238 for ; Thu, 4 Apr 2002 14:49:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27540; Thu, 4 Apr 2002 14:48:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27503 for ; Thu, 4 Apr 2002 14:48:42 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06221 for ; Thu, 4 Apr 2002 14:48:39 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50R7H1>; Thu, 4 Apr 2002 14:48:40 -0500 Message-ID: From: "Folts, Harold" To: "'Marshall Eubanks'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] Public Safety? Date: Thu, 4 Apr 2002 14:48:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Friday, March 29, 2002 10:47 AM > To: Fred Baker; Gunn, Janet NE > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] Public Safety? > > > On Thu, 28 Mar 2002 21:30:50 -0800 > Fred Baker wrote: > > At 02:31 PM 3/28/2002, Gunn, Janet NE wrote: > > > > >If public safety is in scope, land mobile radio > > interoperability (again, > > >specifically out of scope for GETS) is an important > > requirement. During > > >the recovery efforts after 9/11, the the lack of > > interoperability between > > >the land mobile radio networks used by the various > > groups (Police, Fire, > > >Rescue, etc) from different jurisdictions was a major > > problem. It seems > > >plausible that, if each of these systems had an > > interface to the Internet, > > >the Internet could provide the interoperability between > > the systems. > > > > I'm in the market for some words... > > > > Is the focus of this group excusively on voice ? I hope not. PSTN/IP-telephony interface is a first priority to address. Then we need to include the family of multimedia services including, instant messaging, Email, Video, telemedicine (telemetry as well as video), database access, web access, etc. > Wouldn't a instant messager application for emergency > intercommunication be much easier to set up than > interoperating between literally thousands of legacy radio > systems ? > > Regards > Marshall Eubanks > > > > > > _______________________________________________ > > 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 > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 14:52:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06343 for ; Thu, 4 Apr 2002 14:52:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25364; Thu, 4 Apr 2002 14:08:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25330 for ; Thu, 4 Apr 2002 14:08:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04511 for ; Thu, 4 Apr 2002 14:07:59 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14874; Thu, 4 Apr 2002 14:07:29 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08617; Thu, 4 Apr 2002 14:07:30 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Apr 2002 14:07:30 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CDD3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Gunn, Janet NE'" , "'Fred Baker'" , Alistair Munro Cc: ieprep@ietf.org Subject: RE: Scope questions was RE: [Ieprep] a little homily - benefits o f mu lticast Date: Thu, 4 Apr 2002 14:07:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC0B.F7190E90" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC0B.F7190E90 Content-Type: text/plain; charset="ISO-8859-1" You always get to use a spec if you want to; there are no protocol police that limit you to whatever a "applicability statement" says. It isn't clear to me how a totally isolated network would be of much use in an emergency, but you never know. A more likely event is that you have a private network BEHIND A FIREWALL connected to the public network. In an emergency, you would like to be able to jack in to that net and get communications established across the big-I Internet. That has several interesting implications, and I think is well in scope. It would be interesting, for example, to be able to authenticate as an emergency request, and have a firewall alter its policies for you. It would of course be up to local administration to decide what such policies might be, but it sure would be interesting to have a spec that defined the authentication mechanism, and perhaps a recommendation on appropriate policies. For example - when you come to an IETF meeting, you will find that you can easily establish a VPN tunnel back to your "home" network. You will also find that the same thing won't work behind many corporate firewalls. Opening the port that allowed the VPN could be conditional on some sort of authentication mechanism, which would allow it to work for an emergency. Brian -----Original Message----- From: Gunn, Janet NE [mailto:Janet.Gunn@dyncorp.com] Sent: Thursday, April 04, 2002 1:55 PM To: 'Fred Baker'; Alistair Munro Cc: ieprep@ietf.org Subject: Scope questions was RE: [Ieprep] a little homily - benefits of mu lticast Something is not clear to me from the charter. Is the scope of this group restricted to the "public" or "core" Internet, or does it include entrerprize based "private" IP based networks? Janet -----Original Message----- From: Fred Baker [ mailto:fred@cisco.com ] Sent: Thursday, April 04, 2002 12:55 PM At 05:52 AM 4/4/2002, Alistair Munro wrote: >I can't quite parse this, so excuse any misunderstanding. There are >conferencing >applications based on multicast that I have used, and I am sure that you have >too. On the non-interactive side, there is content being distributed from >Internet2 sites using multicast - albeit experimental. Microsoft media server >distributes content using multicast. yes, and those are used in some enterprise environments. Scott is pointing out that there isn't much of this on the backbone. We know that there isn't, because few of the backbone operators enable multicast routing. They have had trouble with it and because they have not been able to obtain revenue from it, so the capability simply doesn't exist in their networks. Intersite multicast across the Internet mostly happens in tunnels. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep ------_=_NextPart_001_01C1DC0B.F7190E90 Content-Type: text/html; charset="ISO-8859-1" Scope questions was RE: [Ieprep] a little homily - benefits of multicast
You always get to use a spec if you want to; there are no protocol police
that limit you to whatever a "applicability statement" says.  It isn't clear to me
how a totally isolated network would be of much use in an emergency, but you
never know.  A more likely event is that you have a private network BEHIND A FIREWALL
connected to the public network.  In an emergency, you would like to be able to
jack in to that net and get communications established across the big-I Internet.
That has several interesting implications, and I think is well in scope.
It would be interesting, for example, to be able to authenticate as an emergency
request, and have a firewall alter its policies for you.  It would of course be
up to local administration to decide what such policies might be, but it sure
would be interesting to have a spec that defined the authentication mechanism,
and perhaps a recommendation on appropriate policies.
 
For example - when you come to an IETF meeting, you will find that you can
easily establish a VPN tunnel back to your "home" network.  You will also find
that the same thing won't work behind many corporate firewalls.  Opening
the port that allowed the VPN could be conditional on some sort of authentication
mechanism, which would allow it to work for an emergency.
 
Brian
-----Original Message-----
From: Gunn, Janet NE [mailto:Janet.Gunn@dyncorp.com]
Sent: Thursday, April 04, 2002 1:55 PM
To: 'Fred Baker'; Alistair Munro
Cc: ieprep@ietf.org
Subject: Scope questions was RE: [Ieprep] a little homily - benefits of mu lticast

Something is not clear to me from the charter.  Is the scope of this group restricted to the "public" or "core" Internet, or does it include entrerprize based "private" IP based networks?

Janet

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, April 04, 2002 12:55 PM
At 05:52 AM 4/4/2002, Alistair Munro wrote:
>I can't quite parse this, so excuse any misunderstanding. There are
>conferencing
>applications based on multicast that I have used, and I am sure that you have
>too. On the non-interactive side, there is content being distributed from
>Internet2 sites using multicast - albeit experimental. Microsoft media server
>distributes content using multicast.

yes, and those are used in some enterprise environments. Scott is pointing
out that there isn't much of this on the backbone. We know that there
isn't, because few of the backbone operators enable multicast routing. They
have had trouble with it and because they have not been able to obtain
revenue from it, so the capability simply doesn't exist in their networks.
Intersite multicast across the Internet mostly happens in tunnels.


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

------_=_NextPart_001_01C1DC0B.F7190E90-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 15:15:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07131 for ; Thu, 4 Apr 2002 15:15:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28883; Thu, 4 Apr 2002 15:10:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28851 for ; Thu, 4 Apr 2002 15:10:55 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07040 for ; Thu, 4 Apr 2002 15:10:52 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50FT3G>; Thu, 4 Apr 2002 15:10:54 -0500 Message-ID: From: "Folts, Harold" To: "'Marshall Eubanks'" , ieprep@ietf.org Subject: RE: [Ieprep] Public Safety? Date: Thu, 4 Apr 2002 15:10:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Friday, March 29, 2002 12:44 PM > To: Gunn, Janet NE; 'Ken Diliberto'; ieprep@ietf.org > Subject: Re: [Ieprep] Public Safety? > > > On Fri, 29 Mar 2002 12:27:33 -0500 > "Gunn, Janet NE" wrote: > > Ken, > > As I understand it, the issue following 9/11 was when > > groups from other > > jurisdictions arrived to help. For instance, at the > > Pentagon, the local MD, > > DC and VA groups had interoperable land mobile radio. > > But when groups from > > southern Virginia and "out of state" arrived to help, > > interoperability > > became an issue. > > > > Fairfax County (where I live) has specialized emergency > teams that go all over the world for disaster relief. > My understanding is > that interoperability is almost always an issue, even > in the US. I could go and ask them directly if this would > be useful. > Interoperability among all the various systems that support emergency operations is a very critical issue that also has to be addessed. I don't think all these issues would involve the IETF, but certainly some consideration must be given. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 15:22:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07302 for ; Thu, 4 Apr 2002 15:22:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29022; Thu, 4 Apr 2002 15:13:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28986 for ; Thu, 4 Apr 2002 15:13:15 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07088 for ; Thu, 4 Apr 2002 15:13:12 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50R8DD>; Thu, 4 Apr 2002 15:13:14 -0500 Message-ID: From: "Folts, Harold" To: "'Marshall Eubanks'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] Public Safety? Date: Thu, 4 Apr 2002 15:13:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Friday, March 29, 2002 12:49 PM > To: Nguyen, An; 'Marshall Eubanks' > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] Public Safety? > > > I would strongly urge (and am working on an I-D for) the > use of multicast to distribute video in this situation, as > it scales well and avoids edge melt-downs. > See, e.g., my presentation to NANOG-23 > Yes this is another important "non-telephony" applications that should be addressed. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 15:29:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07657 for ; Thu, 4 Apr 2002 15:29:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29479; Thu, 4 Apr 2002 15:22:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29442 for ; Thu, 4 Apr 2002 15:22:52 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07349 for ; Thu, 4 Apr 2002 15:22:48 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34KMEqD006736; Thu, 4 Apr 2002 12:22:16 -0800 (PST) Message-Id: <5.1.0.14.2.20020404121959.0d46be58@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 12:21:54 -0800 To: Ken Carlberg From: Fred Baker Subject: Re: Scope questions was RE: [Ieprep] a little homily - benefits o f mu lticast Cc: ieprep@ietf.org In-Reply-To: <15393.1017948341@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:25 AM 4/4/2002, Ken Carlberg wrote: >...at this time i'd like to ask (plead :-) if folks could take a look at > for the record, that is about to expire if it has not already, as it was posted last July and drafts have a six month lifetime. Hence, in February, I took the liberty of reposting it as http://www.ietf.org/internet-drafts/draft-brown-ieprep-sec-00.txt _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 15:32:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07771 for ; Thu, 4 Apr 2002 15:32:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29437; Thu, 4 Apr 2002 15:22:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29400 for ; Thu, 4 Apr 2002 15:22:47 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07346 for ; Thu, 4 Apr 2002 15:22:43 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34KMEqB006736; Thu, 4 Apr 2002 12:22:16 -0800 (PST) Message-Id: <5.1.0.14.2.20020404121515.022df008@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 12:19:07 -0800 To: "Rosen, Brian" From: Fred Baker Subject: RE: Scope questions was RE: [Ieprep] a little homily - benefits o f mu lticast Cc: ieprep@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF57CDD3@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 11:07 AM 4/4/2002, Rosen, Brian wrote: >It isn't clear to me how a totally isolated network would be of much use >in an emergency, but you never know. ask yourself this question. Is AOL an enterprise or a service provider? From the perspective of the *network*, I would say it is an enterprise - it doesn't provide transit services to other networks. What it does is offer application layer services to its subscribers. AOL Instant Messenger is, according to a note someone sent a few days ago, the "instant messaging" provider of choice, because it is widely used and available. I would say that enterprises (like AOL) and service providers (such as Time-Warner, CableVision, and NyserNet, all of whom provided a great deal of service in the weeks following 9/11 in New York) each have their place. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 15:36:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07844 for ; Thu, 4 Apr 2002 15:36:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00621; Thu, 4 Apr 2002 15:35:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00580 for ; Thu, 4 Apr 2002 15:35:45 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07837 for ; Thu, 4 Apr 2002 15:35:41 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23866; Thu, 4 Apr 2002 15:35:10 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27184; Thu, 4 Apr 2002 15:35:10 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Apr 2002 15:35:10 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CDD6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Fred Baker'" Cc: ieprep@ietf.org Subject: RE: Scope questions was RE: [Ieprep] a little homily - benefits o f mu lticast Date: Thu, 4 Apr 2002 15:35:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I think such a network is like an enterprise connected to the Internet. AOL IM is used within AOLs network, but it is also used very extensively via the Internet. I think distinctions like this are relatively unimportant; if in an emergency you can get connectivity between two points that are interesting, and the network, or internetwork, implements a set of IEPS protocols/conventions/policies that allow it to be used in an emergency, then what we do here will have been usefull. Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, April 04, 2002 3:19 PM > To: Rosen, Brian > Cc: ieprep@ietf.org > Subject: RE: Scope questions was RE: [Ieprep] a little homily > - benefits > o f mu lticast > > > At 11:07 AM 4/4/2002, Rosen, Brian wrote: > >It isn't clear to me how a totally isolated network would be > of much use > >in an emergency, but you never know. > > ask yourself this question. Is AOL an enterprise or a service > provider? > From the perspective of the *network*, I would say it is an > enterprise - > it doesn't provide transit services to other networks. What > it does is > offer application layer services to its subscribers. > > AOL Instant Messenger is, according to a note someone sent a > few days ago, > the "instant messaging" provider of choice, because it is > widely used and > available. > > I would say that enterprises (like AOL) and service providers > (such as > Time-Warner, CableVision, and NyserNet, all of whom provided > a great deal > of service in the weeks following 9/11 in New York) each have > their place. > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Thu Apr 4 15:37:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07909 for ; Thu, 4 Apr 2002 15:37:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29520; Thu, 4 Apr 2002 15:22:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29474 for ; Thu, 4 Apr 2002 15:22:54 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07351 for ; Thu, 4 Apr 2002 15:22:50 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34KMEq9006736; Thu, 4 Apr 2002 12:22:15 -0800 (PST) Message-Id: <5.1.0.14.2.20020404121419.0d4945f8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 12:14:47 -0800 To: "Gunn, Janet NE" From: Fred Baker Subject: Re: Scope questions was RE: [Ieprep] a little homily - benefits of mu lticast Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:54 AM 4/4/2002, Gunn, Janet NE wrote: >Something is not clear to me from the charter. Is the scope of this group >restricted to the "public" or "core" Internet, or does it include >entrerprize based "private" IP based networks? it is limited to neither, but its recommendations should apply to both. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 16:27:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09468 for ; Thu, 4 Apr 2002 16:27:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02890; Thu, 4 Apr 2002 16:22:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02862 for ; Thu, 4 Apr 2002 16:22:38 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09262 for ; Thu, 4 Apr 2002 16:22:30 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50FVM1>; Thu, 4 Apr 2002 16:22:21 -0500 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" , "Folts, Harold" Cc: ieprep@ietf.org Date: Thu, 4 Apr 2002 16:22:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: Folts' stated requirements: mobility Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Monday, April 01, 2002 12:31 PM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: Folts' stated requirements: mobility > > > In > http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-p > aper-00.txt, > you state that "A US Government working group recently > identified fourteen > basic functional requirements for the future ETS." > > In section two, you mention > +---------------------------------------------------------------- > |g. Mobility The communications infrastructure must > | support transportable, redeployable, or > | fully mobile communications (e.g., > | personal communications service, > | cellular, satellite, high frequency > | radio). > +---------------------------------------------------------------- > > Is there a problem here that you are seeking to have > addressed? It is my > perception that Internet technology has strong mobility > characteristics; > the laptop has become essentially ubiquitous, PDA-based > Instant Messaging > and Email solutions exist and can be deployed, and we > certainly do hear a > lot about 3G. Are you looking for something different from or > in addition > to the capabilities that are currently available? > there are many support systems that are involved emergency recovery operations that are not immediately on site but can be quickly (hopefully) to the disaster site. Some of these are being addressed by other standards activities. It has been a problem in the past to interoperate with other local systems and the public telecom networks. It would be highly desirable for the various systems to interface and integrate to provide more effective communications during a disaster event. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 16:29:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09606 for ; Thu, 4 Apr 2002 16:29:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03283; Thu, 4 Apr 2002 16:28:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03246 for ; Thu, 4 Apr 2002 16:28:39 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09561 for ; Thu, 4 Apr 2002 16:28:34 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g34LS7q7015927; Thu, 4 Apr 2002 13:28:07 -0800 (PST) Message-Id: <5.1.0.14.2.20020404132350.01e35198@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 13:25:12 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: Folts' stated requirements: mobility Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 01:22 PM 4/4/2002, Folts, Harold wrote: >>Are you looking for something different from or in addition to the >>capabilities that are currently available? > >there are many support systems that are involved emergency recovery >operations that are not immediately on site but can be quickly (hopefully) >to the disaster site. Some of these are being addressed by other standards >activities. It has been a problem in the past to interoperate with other >local systems and the public telecom networks. It would be highly >desirable for the various systems to interface and integrate to provide >more effective communications during a disaster event. Color me dense, but I could work out from what you said what the answer to the question was. Could you try again? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 16:45:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09986 for ; Thu, 4 Apr 2002 16:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04593; Thu, 4 Apr 2002 16:44:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04566 for ; Thu, 4 Apr 2002 16:44:06 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09952 for ; Thu, 4 Apr 2002 16:44:01 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50FV6T>; Thu, 4 Apr 2002 16:44:00 -0500 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" Cc: ieprep@ietf.org Date: Thu, 4 Apr 2002 16:43:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: Folts' stated requirements: security Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, April 02, 2002 3:08 PM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: Folts' stated requirements: security > > > In > http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-p > aper-00.txt, > you state that "A US Government working group recently > identified fourteen > basic functional requirements for the future ETS." > > In section 2, you bring up the issue of security: > +---------------------------------------------------------------- > |b. Secure Networks Networks must have protection against > | corruption of, or unauthorized access to, > | traffic and control, including expanded > | encryption techniques and user > | authentication, as appropriate. > +---------------------------------------------------------------- > > I'm not just certain what direction you want to take this. > There are two security aspects that we are addressing for ETS - authentication of authorized users and protection of ETS traffic from intrusion. It is not meant to address the many other security issues associated with the Internet. For GETS in the PSTN a basic credit card authentication process is used. This needs keying of some 32 digits to establish a call. Hopefully in the future new technology can be applied that will streamline this process. The ETS intrusion security issues are spoofing, impeding ETS traffic (Denial of service), changing content, as well as non-traceability and prevention of eavesdropping for sensitive and confidential traffic for some government officials. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 17:18:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10923 for ; Thu, 4 Apr 2002 17:18:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06780; Thu, 4 Apr 2002 17:16:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06748 for ; Thu, 4 Apr 2002 17:16:18 -0500 (EST) Received: from sven.kdmd.net (adsl-64-160-215-222.dsl.frsn01.pacbell.net [64.160.215.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10889 for ; Thu, 4 Apr 2002 17:16:13 -0500 (EST) Received: from GW-KDMD-Message_Server by sven.kdmd.net with Novell_GroupWise; Thu, 04 Apr 2002 14:16:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 04 Apr 2002 14:15:50 -0600 From: "Ken Diliberto" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA06749 Subject: [Ieprep] RE: Totally isolated networks Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit How about this: A city-wide private network run by the City. This network includes both wired and wireless technologies. This is a totally isolated network if the connection to the Internet disappears. Let's add the desire for external government agencies to share data. Now we have a private Internet. How about a connection for the media (not that they wouldn't already be hounding the brass in-person)? Can you think of others who might benefit by being connected? I can, and the list would be long. The problem I want to see addressed is the different technologies used by each individual government being able to interconnect to assist in disasters. Do we assign IPv6 address blocks to each agency for mobility and the ability to easily connect (just a thought)? Ken At 11:07 AM 4/4/2002, Rosen, Brian wrote: >It isn't clear to me how a totally isolated network would be of much use >in an emergency, but you never know. [snip] _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 17:31:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11237 for ; Thu, 4 Apr 2002 17:31:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07484; Thu, 4 Apr 2002 17:30:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07443 for ; Thu, 4 Apr 2002 17:30:43 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11212 for ; Thu, 4 Apr 2002 17:30:38 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50SAP4>; Thu, 4 Apr 2002 17:30:41 -0500 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" Cc: ieprep@ietf.org Date: Thu, 4 Apr 2002 17:28:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: Folts' stated requirements: mobility Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, April 04, 2002 4:25 PM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: RE: Folts' stated requirements: mobility > > > At 01:22 PM 4/4/2002, Folts, Harold wrote: > >>Are you looking for something different from or in addition to the > >>capabilities that are currently available? > > > >there are many support systems that are involved emergency recovery > >operations that are not immediately on site but can be > quickly (hopefully) > >to the disaster site. Some of these are being addressed by > other standards > >activities. It has been a problem in the past to > interoperate with other > >local systems and the public telecom networks. It would be highly > >desirable for the various systems to interface and integrate > to provide > >more effective communications during a disaster event. > > Color me dense, but I could work out from what you said what > the answer to > the question was. Could you try again? > FEMA has some transportable systems that are unique to them and do not interwork with anything else. The MESA project in ETSI is working on a transportable broadband system for public safety and recovery operations. Local mobile radio systems that do not interwork with other and companion support systems. At the recent ETSI Emtel workshop, it was made very clear by user activities, national and local, having the many different systems supporting emergency operations are incompatible. They would like to be able to have compatible interfaces among then and with the public telecom network to provide better flexibility to integrate all the telecomm services for organizing and coordinating recovery activities. Do these examples help? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 17:34:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11352 for ; Thu, 4 Apr 2002 17:34:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07690; Thu, 4 Apr 2002 17:31:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07661 for ; Thu, 4 Apr 2002 17:31:38 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11250 for ; Thu, 4 Apr 2002 17:31:34 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50SAQ0>; Thu, 4 Apr 2002 17:31:37 -0500 Message-ID: From: "Folts, Harold" To: "'Ken Diliberto'" , ieprep@ietf.org Subject: RE: [Ieprep] RE: Totally isolated networks Date: Thu, 4 Apr 2002 17:31:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Ken Diliberto [mailto:Ken@kdmd.net] > Sent: Thursday, April 04, 2002 3:16 PM > To: ieprep@ietf.org > Subject: [Ieprep] RE: Totally isolated networks > > > How about this: > A city-wide private network run by the City. This network > includes both wired and wireless technologies. This is a > totally isolated network if the connection to the Internet disappears. > > Let's add the desire for external government agencies to > share data. Now we have a private Internet. How about a > connection for the media (not that they wouldn't already be > hounding the brass in-person)? Can you think of others who > might benefit by being connected? I can, and the list would be long. > > The problem I want to see addressed is the different > technologies used by each individual government being able to > interconnect to assist in disasters. Do we assign IPv6 > address blocks to each agency for mobility and the ability to > easily connect (just a thought)? > > Here are some good examples where interoperability among systems can definately benefit recovery operations. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 17:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11633 for ; Thu, 4 Apr 2002 17:45:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08051; Thu, 4 Apr 2002 17:35:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08017 for ; Thu, 4 Apr 2002 17:35:10 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11363 for ; Thu, 4 Apr 2002 17:34:54 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05094; Thu, 4 Apr 2002 17:34:25 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21925; Thu, 4 Apr 2002 17:34:25 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Apr 2002 17:34:25 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CDE1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Ken Diliberto'" , ieprep@ietf.org Subject: RE: [Ieprep] RE: Totally isolated networks Date: Thu, 4 Apr 2002 17:34:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Good point re isolated networks. Let's get the requirements settled before we look at solutions, please. One aspect we might want to explore is whether we see requirements for ADAPTING to various bits that emergency workers might have, or whether we see requirements for specifying new equipment. It's always possible to build gateways, but do we want to see most of the work as specifying how gateways work, or do we want to write specs for new development? The IPv4/6 is a case in point. It might be a good idea to make all of the new work v6 based from the word go. We might then specify the precise tunnel mechanisms to get IPv6 through IPv4 networks. On the other hand, we could just specify the precise requirements for both V4 and V6 equipment as we do for most other specs, and implementations can be either. This is a detail, but the basic question - is this lots of gateways, or specs to build new systems, is a pretty important question. You know that in reality the answer is BOTH, but you still get to ask if the main thrust assumes new stuff, or assumes work-with-what-you-got. Brian > -----Original Message----- > From: Ken Diliberto [mailto:Ken@kdmd.net] > Sent: Thursday, April 04, 2002 3:16 PM > To: ieprep@ietf.org > Subject: [Ieprep] RE: Totally isolated networks > > > How about this: > A city-wide private network run by the City. This network > includes both wired and wireless technologies. This is a > totally isolated network if the connection to the Internet disappears. > > Let's add the desire for external government agencies to > share data. Now we have a private Internet. How about a > connection for the media (not that they wouldn't already be > hounding the brass in-person)? Can you think of others who > might benefit by being connected? I can, and the list would be long. > > The problem I want to see addressed is the different > technologies used by each individual government being able to > interconnect to assist in disasters. Do we assign IPv6 > address blocks to each agency for mobility and the ability to > easily connect (just a thought)? > > Ken > > > At 11:07 AM 4/4/2002, Rosen, Brian wrote: > >It isn't clear to me how a totally isolated network would be > of much use > >in an emergency, but you never know. > > [snip] > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Thu Apr 4 17:48:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11744 for ; Thu, 4 Apr 2002 17:48:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04099; Thu, 4 Apr 2002 16:35:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04069 for ; Thu, 4 Apr 2002 16:35:47 -0500 (EST) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09788 for ; Thu, 4 Apr 2002 16:35:43 -0500 (EST) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2B50FVWA>; Thu, 4 Apr 2002 16:35:46 -0500 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" Cc: ieprep@ietf.org Date: Thu, 4 Apr 2002 16:35:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: Folts' stated requirements - voiceband and broadband services Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, April 02, 2002 3:08 PM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: Folts' stated requirements - voiceband and broadband services > > > In > http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-p > aper-00.txt, > you state that "A US Government working group recently > identified fourteen > basic functional requirements for the future ETS." > > In section 2, you state that there is a requirement for > +---------------------------------------------------------------- > |j. Voice Band Service The service must provide voice band > | service in support of presidential and > | other communications. > +---------------------------------------------------------------- > |k. Broadband Service The service must provide broadband > | service in support of NS/EP missions > | (e.g., video, imaging, web access, > | multimedia). > +---------------------------------------------------------------- > > It's not clear to me what you are calling for here. Are you > asking for the > network to have built-in services that provide, for example, TV-like > broadcast capabilities? Are you looking for the ability to > place VoIP phone > calls? > > Specifically what problems do you see needing solution in this arena? > I don't think that there is any problem to solve here that the IETF is concerned with, but this is more an application issue in fulfilling many different aspects of communications for national security and emergency preparedness _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 17:50:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11807 for ; Thu, 4 Apr 2002 17:50:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08407; Thu, 4 Apr 2002 17:46:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08376 for ; Thu, 4 Apr 2002 17:46:49 -0500 (EST) Received: from sven.kdmd.net (adsl-64-160-215-222.dsl.frsn01.pacbell.net [64.160.215.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11693 for ; Thu, 4 Apr 2002 17:46:44 -0500 (EST) Received: from GW-KDMD-Message_Server by sven.kdmd.net with Novell_GroupWise; Thu, 04 Apr 2002 14:46:46 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 04 Apr 2002 14:46:06 -0600 From: "Ken Diliberto" To: Subject: RE: [Ieprep] RE: Totally isolated networks Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA08377 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit In keeping with Freds wishes (and, not knowing how much hair he has left to pull out), I'm trying to address a problem with each of my ideas. Having worked in the public sector gives me a great vantage point for potential problems. Ken >>> "Folts, Harold" 04/04/02 04:31PM >>> > -----Original Message----- > From: Ken Diliberto [mailto:Ken@kdmd.net] > Sent: Thursday, April 04, 2002 3:16 PM > To: ieprep@ietf.org > Subject: [Ieprep] RE: Totally isolated networks > > > How about this: > A city-wide private network run by the City. This network > includes both wired and wireless technologies. This is a > totally isolated network if the connection to the Internet disappears. > > Let's add the desire for external government agencies to > share data. Now we have a private Internet. How about a > connection for the media (not that they wouldn't already be > hounding the brass in-person)? Can you think of others who > might benefit by being connected? I can, and the list would be long. > > The problem I want to see addressed is the different > technologies used by each individual government being able to > interconnect to assist in disasters. Do we assign IPv6 > address blocks to each agency for mobility and the ability to > easily connect (just a thought)? > > Here are some good examples where interoperability among systems can definately benefit recovery operations. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 18:53:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13056 for ; Thu, 4 Apr 2002 18:53:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11598; Thu, 4 Apr 2002 18:46:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11542 for ; Thu, 4 Apr 2002 18:46:30 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12937 for ; Thu, 4 Apr 2002 18:46:24 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA15932 for ; Thu, 4 Apr 2002 15:45:57 -0800 (PST) Message-Id: <4.1.20020404172605.0cde57d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Apr 2002 17:45:26 -0600 To: ieprep@ietf.org From: "James M. Polk" Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1106052479==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_1106052479==_.ALT Content-Type: text/plain; charset="us-ascii" At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote: > > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, March 25, 2002 1:24 PM > To: ieprep@ietf.org > Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority >> >> At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: >>> >>> Ken, >>> >>> I believe that Hal is now using the term ETS (Emergency Telecommunications >>> Service) rather than ECS. >> >> I have an issue with this change in view of the IEPREP Charter addressing >> more than Voice (ie Telecommunications) -- and of the two then prefer ECS >> (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA >> uses) >> >> >> >> [HF] The term "communication is too general and can include postal service >> and smoke signals. Telecommunications is appropriate and should not be >> limited to voice or telephony. I consider telecom. to apply equally to the >> Internet and all modes in a network infrastructure. > "Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID) for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on limiting focus to only voice (which you state as not being your desires here, which I agree with BTW) > >> >> >> Hal > > > > ************************************* > "People generally demand more respect for their own rights than they are > willing to allow for others" > > James M. Polk > Consulting Engineer > Office of the CTO > > Cisco Systems > 2200 East President George Bush Turnpike > Richardson, TX 75082 USA > w) 972.813.5208 > f) 972.813.5280 > www.cisco.com --=====================_1106052479==_.ALT Content-Type: text/html; charset="us-ascii" At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote:
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, March 25, 2002 1:24 PM
To: ieprep@ietf.org
Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority
At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote:
Ken,

I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS.
I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses)



[HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure.

"Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID)  for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on  limiting focus to only voice (which you state as not being your desires here, which I agree with BTW)
 
Hal


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1106052479==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 19:28:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13957 for ; Thu, 4 Apr 2002 19:28:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13748; Thu, 4 Apr 2002 19:28:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13676 for ; Thu, 4 Apr 2002 19:28:42 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13948 for ; Thu, 4 Apr 2002 19:28:39 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g350S7qB029751; Thu, 4 Apr 2002 16:28:10 -0800 (PST) Message-Id: <5.1.0.14.2.20020404155129.0d4b53b0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 15:57:25 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: Folts' stated requirements: mobility Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 02:28 PM 4/4/2002, Folts, Harold wrote: >Do these examples help? not really. You state that the US Government is interested in the ETS having an attribute called "mobility". What do you want to be mobile? Is this a handset question? Is this a question of occasionally moving laptops? Is this a question of being able to bring in an internet-on-wheels comparable to the Mobile Telephone Networks' Cell-on-wheels? When you say "mobile", do you mean that the address of the device needs to appear to be stationary within some network, although the device is moving within an external stationary infrastructure? This is what Mobile IP gives you. Do you mean that the corporate/government internal network that the device is part of needs to be extensible through an encrypted tunnel to make a moving device operationally part of it? That is what an IPSEC of SSH VPN would give you. Do you mean that there might be no infrastructure other than the internet devices actually there, so they need to be able to operationally morph their network topology among themselves as the Army WIN-T program envisions? If so, we're discussing mobile ad hoc routing. I need to understand what you expect to move, and what the ramifications of its motion are. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 19:33:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14045 for ; Thu, 4 Apr 2002 19:33:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13713; Thu, 4 Apr 2002 19:28:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13671 for ; Thu, 4 Apr 2002 19:28:41 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13946 for ; Thu, 4 Apr 2002 19:28:36 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g350S7q9029751; Thu, 4 Apr 2002 16:28:08 -0800 (PST) Message-Id: <5.1.0.14.2.20020404153609.0d4b3008@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 15:50:57 -0800 To: "Folts, Harold" From: Fred Baker Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: Folts' stated requirements: security Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 01:43 PM 4/4/2002, Folts, Harold wrote: >For GETS in the PSTN a basic credit card authentication process is used. OK, so one issue is the authentication method. Presumably, GETS-in-the-Internet wants to use the same card. The IETF isn't going to standardize the US Government's credit card (presumably it doesn't have to), but there should be an appropriate mechanism that the credit card information could be fed into to identify the device to a network that has an appropriate contract with the US Government. This sounds to me like some variation on a AAA question. There is either going to be a standard RADIUS/DIAMETER/whatever protocol exchange between a specified application on the laptop for the purpose, or there is going to be a web page that the laptop displays that has the relevant fields. Is it fair to say that the US Government's requirement is that one of those two mechanisms exist for any business that it writes such a contract with? Is it fair to then write a requirements document (a short one) that specifies the expectations so that it can be referred to by (a) the AAA Working Group, which is writing the DIAMETER-based protocols, and (b) a business that chooses to contract with the US Government? Could we identify someone to write that hopefully-short internet draft, specifying the information that AAA WG needs, and pointing to the USG document for further detail? >This needs keying of some 32 digits to establish a call. Hopefully in the >future new technology can be applied that will streamline this process. gee whiz; I use a program called "soft-token", to which I authenticate using a PIN, and which then gives me a one-time password. I click on something and it gets copied to the clipboard, I select where I want it to go, and I click something else to make the clip-board contents be there. That's a UI issue. What the IETF works on are protocol issues; I would assume that the 32 digits are functionally the same; all we need is an appropriate attribute in DIAMETER that can carry the digits, right? >The ETS intrusion security issues are spoofing, impeding ETS traffic >(Denial of service), changing content, as well as non-traceability and >prevention of eavesdropping for sensitive and confidential traffic for >some government officials. Again, this sounds like a combination of UI, service, and protocol issues. IPSEC Authentication and Encryption, TLS encryption, SSL, MIME, and so on already exist. If we can identify the requirements for the protocol part (does it need to work through a NAT, for example?), our part should be fairly straightforward. The service issues become issues such as: does AOL or whoever have to implement encryption within Instant Messenger, and does that have to extend to the blackberry or whatever? Those, we can write an internet draft to specify, but at the bottom line they are contract issues between the US Government and its contractor networks. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 19:44:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14163 for ; Thu, 4 Apr 2002 19:44:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14717; Thu, 4 Apr 2002 19:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14683 for ; Thu, 4 Apr 2002 19:43:37 -0500 (EST) Received: from chntex01.is.dyncorp.com (chntex01.is.dyncorp.com [131.131.133.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14157 for ; Thu, 4 Apr 2002 19:43:33 -0500 (EST) Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <2JPVJ9FD>; Thu, 4 Apr 2002 19:41:53 -0500 Message-ID: From: "Gunn, Janet NE" To: "'James M. Polk'" , ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority Date: Thu, 4 Apr 2002 19:42:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC3A.D18F7C20" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC3A.D18F7C20 Content-Type: text/plain; charset="iso-8859-1" I've also worked with people who used "telecommunications" to mean "data communications" (including the LAN, which annoyed the h&** out of me) and "telephony" to mean voice. I think the usage is very non-standardized, and whatever we decide, SOMEONE will think we meant something different. -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, April 04, 2002 6:45 PM To: ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote: -----Original Message----- From: James M. Polk [ mailto:jmpolk@cisco.com ] Sent: Monday, March 25, 2002 1:24 PM To: ieprep@ietf.org Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: Ken, I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS. I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses) [HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure. "Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID) for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on limiting focus to only voice (which you state as not being your desires here, which I agree with BTW) Hal ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1DC3A.D18F7C20 Content-Type: text/html; charset="iso-8859-1"
I've also worked with people who used "telecommunications" to mean "data communications" (including the LAN, which annoyed the h&** out of me) and "telephony" to mean voice. 
 
I think the usage is very non-standardized, and whatever we decide, SOMEONE will think we meant something different.
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Thursday, April 04, 2002 6:45 PM
To: ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority

At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote:
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, March 25, 2002 1:24 PM
To: ieprep@ietf.org
Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority
At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote:
Ken,

I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS.
I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses)



[HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure.

"Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID)  for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on  limiting focus to only voice (which you state as not being your desires here, which I agree with BTW)
Hal


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
------_=_NextPart_001_01C1DC3A.D18F7C20-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 4 20:53:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14864 for ; Thu, 4 Apr 2002 20:53:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17580; Thu, 4 Apr 2002 20:45:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16497 for ; Thu, 4 Apr 2002 20:25:10 -0500 (EST) Received: from prserv.net (asmtp1.prserv.net [32.97.166.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14577 for ; Thu, 4 Apr 2002 20:25:08 -0500 (EST) Received: from u4gbb (slip-32-102-157-199.md.us.prserv.net[32.102.157.199]) by prserv.net (asmtp1) with SMTP id <2002040501250725104e46pde> (Authid: usinet.capthal); Fri, 5 Apr 2002 01:25:07 +0000 From: "Hal Folts" To: "Gunn, Janet NE" Cc: Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority Date: Thu, 4 Apr 2002 20:33:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01C1DC18.0B8FE4F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C1DC18.0B8FE4F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002D_01C1DC18.0B978610" ------=_NextPart_001_002D_01C1DC18.0B978610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of Gunn, Janet NE Sent: Thursday, April 04, 2002 7:43 PM To: 'James M. Polk'; ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority I've also worked with people who used "telecommunications" to mean "data communications" (including the LAN, which annoyed the h&** out of me) and "telephony" to mean voice. I think the usage is very non-standardized, and whatever we decide, SOMEONE will think we meant something different. Janet, where have you been. I have been in the telecommunications business for over forty years now and the definition is very clear. Telecommunications is a means of conveying communications and information via electrical means, including telegraphy, data communications, wireless, telephony, etc. Let's not try to be clever and try to define new terms. Telecommunications is not restricted to voice only. Data Communications is a subset of telecommunications. The ITU International Telecommunication Union was founded in 1863 when Marconi started to send radio waves and morse invented his code. Let's not waste anymore time on this issue!! -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, April 04, 2002 6:45 PM To: ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote: -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, March 25, 2002 1:24 PM To: ieprep@ietf.org Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: Ken, I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS. I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses) [HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure. "Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID) for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on limiting focus to only voice (which you state as not being your desires here, which I agree with BTW) Hal ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------=_NextPart_001_002D_01C1DC18.0B978610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----Original = Message-----
From:=20 ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of = Gunn,=20 Janet NE
Sent: Thursday, April 04, 2002 7:43 PM
To: = 'James=20 M. Polk'; ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" = priority=20 value for Resource-Priority

I've=20 also worked with people who used "telecommunications" to mean "data=20 communications" (including the LAN, which annoyed the h&** out of = me) and=20 "telephony" to mean voice. 
 
I think the usage is very non-standardized, and whatever we = decide,=20 SOMEONE will think we meant something different. 
 
Janet, where have you been. = I have been=20 in the telecommunications business for over forty years now and the = definition=20 is very clear. Telecommunications is a means of conveying = communications=20 and information via electrical means, including telegraphy, data=20 communications, wireless, telephony, etc. Let's not try to be clever = and try=20 to define new terms.  Telecommunications is not restricted to = voice only.=20 Data Communications is a subset of telecommunications. The ITU = International=20 Telecommunication Union was founded in 1863 when Marconi started to = send radio=20 waves and morse invented his code. Let's not waste anymore time on = this=20 issue!!
-----Original Message-----
From: James M. Polk=20 [mailto:jmpolk@cisco.com]
Sent: Thursday, April 04, 2002 = 6:45=20 PM
To: ieprep@ietf.org
Subject: RE: [Ieprep] = "IEPREP"=20 priority value for Resource-Priority

At 01:04 PM = 4/4/2002 -0500, Folts, Harold wrote:
-----Original = Message-----
From:=20 James M. Polk [mailto:jmpolk@cisco.com]
Sent: = Monday,=20 March 25, 2002 1:24 PM
To: = ieprep@ietf.org
Subject:=20 Re: [Ieprep] "IEPREP" priority value for = Resource-Priority
At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote:=20
Ken,

I believe that Hal is now using the term ETS (Emergency=20 Telecommunications Service) rather than ECS. =
I have an issue with this change in view of the IEPREP = Charter=20 addressing more than Voice (ie Telecommunications) -- and of = the two=20 then prefer ECS (which could mean anything from Voice to IM to = FTP to=20 HTTP to whatever IAA uses)



[HF] The term "communication is too general and can = include postal=20 service and smoke signals. Telecommunications is appropriate = and=20 should not be limited to voice or telephony. I consider = telecom. to=20 apply equally to the Internet and all modes in a network=20 infrastructure.

"Tele" means 'over some(long) distance(s)' -- so = strictly=20 speaking (writing), you're correct with your intention. But most of = us in=20 this community know there is a difference in most networks - = especially in=20 closed networks like enterprises where most of us work - between=20 Telecommunications and Datacommunications. The former means "voice", = the=20 latter means "everything else". FTP, SMTP and HTTP (3 desirable = applications=20 from your ID)  for example will always fall under the=20 "Datacommunications" side of this categorization, not to the=20 Telecommunications side. I would consider "communications" to be a = better=20 word than "Telecom", "Datacom", "Transfer", or any others I've heard = or read=20 or thought of. I'm looking at it to relieve confusion on  = limiting=20 focus to only voice (which you state as not being your desires here, = which I=20 agree with BTW)
Hal


*************************************
"People=20 generally demand more respect for their own rights than they are = willing=20 to allow for others"

James M. Polk
Consulting=20 Engineer
Office of the CTO

Cisco Systems
2200 East = President=20 George Bush Turnpike
Richardson, TX  75082 USA
w)=20 972.813.5208
f)  972.813.5280
www.cisco.com=20
------=_NextPart_001_002D_01C1DC18.0B978610-- ------=_NextPart_000_002C_01C1DC18.0B8FE4F0 Content-Type: text/x-vcard; name="Hal Folts.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Hal Folts.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Folts;Hal FN:Hal Folts ADR:;;400 Holloway Ct. NE;Vienna;VA;22180-3545;USA TEL;WORK:+1 703 607-6186 TEL;HOME:+1 703 281-3245 TEL:+1 703 281-0761 (24 hours) EMAIL:catching@captainhal.com END:VCARD ------=_NextPart_000_002C_01C1DC18.0B8FE4F0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 03:24:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00034 for ; Fri, 5 Apr 2002 03:24:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15286; Fri, 5 Apr 2002 03:17:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15251 for ; Fri, 5 Apr 2002 03:17:52 -0500 (EST) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29988 for ; Fri, 5 Apr 2002 03:17:41 -0500 (EST) Received: from host213-122-111-108.in-addr.btopenworld.com ([213.122.111.108] helo=degree2.com) by carbon with esmtp (Exim 3.22 #8) id 16tOtG-0002LK-00; Fri, 05 Apr 2002 09:16:10 +0100 Message-ID: <3CAD5D70.6140F860@degree2.com> Date: Fri, 05 Apr 2002 09:16:48 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Ken Diliberto'" , ieprep@ietf.org Subject: Re: [Ieprep] RE: Totally isolated networks References: <313680C9A886D511A06000204840E1CF57CDE1@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, > Let's get the requirements settled before we look at solutions, please. > > One aspect we might want to explore is whether we see requirements for > ADAPTING to various bits that emergency workers might have, or whether > we see requirements for specifying new equipment. It's always possible > to build gateways, but do we want to see most of the work as specifying > how gateways work, or do we want to write specs for new development? > I don't see this as the remit of this WG and it doesn't appear to be consistent with the charter. It seems to be telling users what to do. Also gateways are always part of a solution - not part of the requirements that you have just urged us to settle first! > > The IPv4/6 is a case in point. It might be a good idea to make all of the > new work v6 based from the word go. We might then specify the precise > tunnel > mechanisms to get IPv6 through IPv4 networks. On the other hand, we could > just specify the precise requirements for both V4 and V6 equipment as we > do for most other specs, and implementations can be either. This is a > detail, > but the basic question - is this lots of gateways, or specs to build new > systems, is a pretty important question. > It would be a big mistake to assume that IP is not used already for supporting emergency service applications. Therefore there is almost certainly a legacy to incorporate. I don't think developers of emergency services need to be told what to build, but the job of this group (as I interpret it) is to inform them what is there and how best to use it. Tunneling specifications exist already - we need only refer to them. On Ken's points: > > > > The problem I want to see addressed is the different > > technologies used by each individual government being able to > > interconnect to assist in disasters. Do we assign IPv6 > > address blocks to each agency for mobility and the ability to > > easily connect (just a thought)? Interconnection is not a problem for this group. We can put any solution we like on the table but that will not encourage agencies to work together. Go to any APCO conference (I'm sure you have done) and you will hear that it is not lack of technology or specifications to interconnect systems. It is the human problem that prevents it. Also, address assignment is not done that way, nor would it solve any problems. In particular it would make no difference to the probably desirable outcome that we are able to make emergency services a commodity to be picked up where they are on offer, or at least transportable to the extent that they can be installed on demand into any available local infrastucture. I believe that the protocols exist to do this already; it is information on best practice that is missing. If there is no best practice or any practice at all then we will have to be cautious in our guidance. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 04:16:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00491 for ; Fri, 5 Apr 2002 04:16:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17688; Fri, 5 Apr 2002 04:07:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17633 for ; Fri, 5 Apr 2002 04:07:14 -0500 (EST) Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00410 for ; Fri, 5 Apr 2002 04:07:10 -0500 (EST) Received: from host213-122-176-56.in-addr.btopenworld.com ([213.122.176.56] helo=degree2.com) by protactinium with esmtp (Exim 3.22 #8) id 16tPgK-0002Vz-00; Fri, 05 Apr 2002 10:06:53 +0100 Message-ID: <3CAD6952.159DF71@degree2.com> Date: Fri, 05 Apr 2002 10:07:30 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: "Folts, Harold" , ieprep@ietf.org Subject: Re: [Ieprep] RE: Folts' stated requirements: mobility References: <5.1.0.14.2.20020404155129.0d4b53b0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > [Do the examples from Hal Folts help?] ...not really. You state that the US > Government is interested in the ETS > having an attribute called "mobility". > .... > I need to understand what you expect to move, and what the ramifications of > its motion are. I would expect the bits with antennas to move, i.e. any terminal (handset, laptop, PDA) and base-station. Depending on the mobility support in the infrastructure, and whether it is shared or not, there may be no requirement to change layer 2 or layer 3 interface addresses. E.g. if the service is supported in a single GSM or TETRA infrastructure (or similar wherever you might be) the terminal can move anywhere within it without any change of IP address. The network may be closed/isolated or not. But this is far too simplistic in my opinion although it would probably be enough in many situations. If a terminal moves out of its home network then we are in the mobile IP domain if we want it to keep its permanent address - which I would say we do if we want to place a call to it peer-to-peer. However, DHCP and fast DNS update are also solutions with different overheads. This would apply to terminals that move within range of an agency or ISP WLAN access point. For the agency case, the terminal may not appear to be mobile, unless it is roamed in from another agency - mobile-IP again. For the ISP case, we are back to asking what an ISP would have to do to host emergency calls and possibly services. However many applications do not need a permanent IP address - it is a trade-off between the overheads of mobility management and re-registering your identity with the necessary services. I suspect security overheads will be similar in either scheme. For the case where the whole network is mobile, I think we ought to exclude this. It is mainly a military requirement. The case where the emergency services are mobile and installable on demand in a host network may be quite simple. Mobile-IP, or DHCP/fast DNS update support the terminals and appropriate security protocols: SSL, IPSEC VPNs do the protection. DiffServ would have to be enabled - on-demand? (up to the provider I guess). I think I am agreeing with Fred's suggestions. At least I feel confident now that I can do an implementation with these protocols in a purpose built network. Personally I think that this is 90% of our job done on what we think the requirements are, but I still miss thoughts from the agencies, suppliers to and users of emergency services. Also, mobile-IP may fall into the same category as multicast - where is the best practice to point people at? Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 04:35:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00710 for ; Fri, 5 Apr 2002 04:35:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18696; Fri, 5 Apr 2002 04:30:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18655 for ; Fri, 5 Apr 2002 04:30:52 -0500 (EST) Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00671 for ; Fri, 5 Apr 2002 04:30:47 -0500 (EST) Received: from host213-122-21-144.in-addr.btopenworld.com ([213.122.21.144] helo=degree2.com) by protactinium with esmtp (Exim 3.22 #8) id 16tQ3O-0004mh-00; Fri, 05 Apr 2002 10:30:43 +0100 Message-ID: <3CAD6EE8.F72036D0@degree2.com> Date: Fri, 05 Apr 2002 10:31:20 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hal Folts CC: "Gunn, Janet NE" , ieprep@ietf.org Subject: Re: [Ieprep] telecommunications - wot that? References: Content-Type: multipart/alternative; boundary="------------8E3B25C96F2A67C6CFA4EB8A" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --------------8E3B25C96F2A67C6CFA4EB8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, This exchange must be going nowhere... I feel as if we are digging up someone's grave. > "Tele" means 'over some(long) distance(s)' -- so > strictly speaking (writing), you're correct with > your intention. But most of us in this community > know there is a difference in most networks - > especially in closed networks like enterprises > where most of us work - between Telecommunications > and Datacommunications. The former means "voice", > the latter means "everything else". > "Tele" means "at a distance"; "phony" relates to sound, not fakery; data and voice are services; IP, X.25, etc., etc. are protocols at various internetworking layers - packet mode, circuit-mode, synchronous, asynchronous, whatever; LANs, I-, V- series are physical/media layers; FTP, voice, fax, SMTP are applications. They are all part of telecommunications. It doesn't matter anyway. Emergency services and preparedness require them all and the Internet is in a position to support them all - cheaper, faster, better GoS, etc. Can there really be any doubt about scope? It is the agencies' and vendors' choice as to what they implement, not to impose restrictions on what this WG recommends. From my position, there are many actors that want to move to an exclusively IP platform for many key services. This WG is going to deliver the information I/they need. Regards, Alistair --------------8E3B25C96F2A67C6CFA4EB8A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

This exchange must be going nowhere... I feel as if we are digging up someone's grave.

"Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else".
"Tele" means "at a distance"; "phony" relates to sound, not fakery; data and voice are services; IP, X.25, etc., etc. are protocols at various internetworking layers - packet mode, circuit-mode, synchronous, asynchronous, whatever; LANs, I-, V- series are physical/media layers; FTP, voice, fax, SMTP are applications. They are all part of telecommunications.

It doesn't matter anyway. Emergency services and preparedness require them all and the Internet is in a position to support them all - cheaper, faster, better GoS, etc. Can there really be any doubt about scope? It is the agencies' and vendors' choice as to what they implement, not to impose restrictions on what this WG recommends.

From my position, there are many actors that want to move to an exclusively IP platform for many key services. This WG is going to deliver the information I/they need.

Regards,

Alistair --------------8E3B25C96F2A67C6CFA4EB8A-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 04:55:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00939 for ; Fri, 5 Apr 2002 04:55:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19779; Fri, 5 Apr 2002 04:51:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19746 for ; Fri, 5 Apr 2002 04:51:09 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00906 for ; Fri, 5 Apr 2002 04:51:04 -0500 (EST) Received: from host213-122-134-119.in-addr.btopenworld.com ([213.122.134.119] helo=degree2.com) by gadolinium.btinternet.com with esmtp (Exim 3.22 #8) id 16tQMm-0006Ns-00; Fri, 05 Apr 2002 10:50:44 +0100 Message-ID: <3CAD738A.C7B69DF5@degree2.com> Date: Fri, 05 Apr 2002 10:51:07 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Bogdanovic , ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <200204041804.g34I4qx01166@volta.mazunetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Dean, You are right, I am talking c**p and have got my G's mixed up. Sorry if there was any confusion. > G711 (every 8 msec one 64 byte voiceframe is produced) codec is not > compresing voice at all. It is 64kbps per voice call on top of that is > the IP and other headers, comes to aprox 80kbps. So, you are saying at > roughly 80 percent packetloss speech was intelligible? I'll check what codec I am using on the IP phones, but it is definitely a standard 8Kbps one which generates around 16 Kbps of RTP frames per direction (as measured by my LAN analyser and by the element itself). It is a G.7xx, but obviously I do not mean the 64 Kbps one. The speech was barely intelligible at 10 Kbps, at around 30% - 40% maximum loss. For bursty competing streams available bandwidth would often exceed 10 Kbps. For CBR loads intelligibility is very poor. It would never pass toll-quality analysis. > Did you use some compression on datagrams or? Because with > that big packetloss, G711 is not producing good quality, at least in > my experience. No compression, just off-the-shelf stuff. Plug in, find the gatekeeper and go - which is what IP telephony ought to be... There are many lower rate codecs that would run happily in 10 Kbps. But this is not the point. As far as recommendations from this WG are concerned, Fred Baker's requirements document refers to a possible QoS configuration. If emergency services base their DiffServ set up on this basic framework then they will have to choose bandwidth allocations, drop precedences, etc. to suit their traffic mixes, applications (i.e. codecs) and the quality they want to deliver. I am trying to draw attention to the many possibilities that they could draw on. We will not be specifying codecs but we must give guidelines on deployment. Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 05:51:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01466 for ; Fri, 5 Apr 2002 05:51:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22100; Fri, 5 Apr 2002 05:38:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22069 for ; Fri, 5 Apr 2002 05:38:32 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01376 for ; Fri, 5 Apr 2002 05:38:26 -0500 (EST) Received: from 213.78.80.126 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Apr 2002 11:38:20 +0100 From: Ian Brown To: Fred Baker , "Folts, Harold" Cc: ieprep Subject: RE: [Ieprep] RE: Folts' stated requirements: security Date: Fri, 5 Apr 2002 11:39:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20020404153609.0d4b3008@mira-sjcm-4.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > OK, so one issue is the authentication method. Presumably, > GETS-in-the-Internet wants to use the same card. There needs to be authorisation of at least the following, from most basic to more complex: (1) That an emergency worker's IP device be allowed to use a given network (eg a local 802.11 net). If a remote network has a roaming agreement with the emergency worker's home network, it can use AAA to authenticate the device. The necessary secrets can be stored on the device (say in a SIM) or be user-entered (such as a GETS-type PIN). (2) That a user is authorised for particular layer 7 priority mechanisms in a server (such as a telephony gateway). This is relatively simple if a device just connects to servers within its home domain. The authorisation could be done as part of the user registration, or even just using the exact same method per-call as GETS (user calls a non-geographical number which is recognised by the telephony gateway or an element in the PSTN, which then verifies the GETS PIN). This gets trickier if we want roaming devices to be able to get this type of priority in servers on remote networks. (3) That a given device is authorised to use (ie has paid for) particular layer 2/3 priority mechanisms (such as a given AF queue). This would most likely happen as part of the DIAMETER exchange in (1). So we might need to ask the AAA group to support this functionality. This would be useful for any kind of roaming QoS support. > This sounds to me like some variation on a AAA question. There is either > going to be a standard RADIUS/DIAMETER/whatever protocol exchange > between a > specified application on the laptop for the purpose, or there is going to > be a web page that the laptop displays that has the relevant fields. > > Is it fair to say that the US Government's requirement is that > one of those > two mechanisms exist for any business that it writes such a > contract with? > Is it fair to then write a requirements document (a short one) that > specifies the expectations so that it can be referred to by (a) the AAA > Working Group, which is writing the DIAMETER-based protocols, and (b) a > business that chooses to contract with the US Government? > > Could we identify someone to write that hopefully-short internet draft, > specifying the information that AAA WG needs, and pointing to the USG > document for further detail? I can write this, or add it to the security draft. > >This needs keying of some 32 digits to establish a call. Hopefully in the > >future new technology can be applied that will streamline this process. > > gee whiz; I use a program called "soft-token", to which I authenticate > using a PIN, and which then gives me a one-time password. I click on > something and it gets copied to the clipboard, I select where I > want it to > go, and I click something else to make the clip-board contents be there. > That's a UI issue. What the IETF works on are protocol issues; I would > assume that the 32 digits are functionally the same; all we need is an > appropriate attribute in DIAMETER that can carry the digits, right? (or ideally something that reveals the PIN to as few intermediate elements as possible). Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 07:54:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03281 for ; Fri, 5 Apr 2002 07:54:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28023; Fri, 5 Apr 2002 07:54:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27986 for ; Fri, 5 Apr 2002 07:53:56 -0500 (EST) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03256 for ; Fri, 5 Apr 2002 07:53:50 -0500 (EST) Received: from degree2.com (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g35Crm310236; Fri, 5 Apr 2002 13:53:48 +0100 Message-ID: <3CAD9F57.90807@degree2.com> Date: Fri, 05 Apr 2002 13:57:59 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast References: <798.1018010295@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ken, >I have an open ear to adding text to the current draft on subjects it >doesn't cover, but i'll take a very cautious approach regarding codecs >because i have the (possibly mis)conception that the subject really >gets rather implementation/deployment specific. > Yes, I would leave people to make their own decisions on implementation, deployment etc. I was wondering if there were any issues in the interworking of different operational networks, but decided that protocols exist to arbitrate the selection of codecs (does SIP do this? my H.323 setup seems happy to switch) and transcoding at boundaries is (a) done, (b) not an issue for this WG, except possibly to remark on QoS and bandwidth allocation. Any comments on this will apply to video and voice. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.degree2.com, http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 08:06:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03528 for ; Fri, 5 Apr 2002 08:06:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27580; Fri, 5 Apr 2002 07:38:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27549 for ; Fri, 5 Apr 2002 07:38:25 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02956 for ; Fri, 5 Apr 2002 07:38:20 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Apr 2002 13:38:16 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Alistair Munro cc: ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast In-reply-to: Your message of "Fri, 05 Apr 2002 10:51:07 BST." <3CAD738A.C7B69DF5@degree2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 13:38:15 +0100 Message-ID: <798.1018010295@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org hi, > As far as recommendations from this WG are concerned, Fred Baker's > requirements document refers to a possible QoS configuration. If > emergency services base their DiffServ set up on this basic framework > then they will have to choose bandwidth allocations, drop precedences, > etc. to suit their traffic mixes, applications (i.e. codecs) and the > quality they want to deliver. I am trying to draw attention to the many > possibilities that they could draw on. We will not be specifying codecs > but we must give guidelines on deployment. one thing to keep in mind is that Fred's requirement draft uses GETS and the more general concept of IEPS as a foundation for putting forth requirements. and these Requirements stress no specific solution, though the draft does raise issues and an example or two as food for thought. the Framework document starts the process of providing some guidance in terms of IETF protocols and services. in certain places, it provides some specific guidance (such as pointing out the optional Resource-header field for SIP), and in others it just says what exists in a given area along with a "buyer beware" attitude where it seems appropriate. so, to a degree, it does what you state at the end of your above comment, but it does so with respect to GETS-like service as a target model. this keeps the draft grounded so that it doesn't jump all over the place. I have an open ear to adding text to the current draft on subjects it doesn't cover, but i'll take a very cautious approach regarding codecs because i have the (possibly mis)conception that the subject really gets rather implementation/deployment specific. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 08:27:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03997 for ; Fri, 5 Apr 2002 08:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29295; Fri, 5 Apr 2002 08:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29266 for ; Fri, 5 Apr 2002 08:23:27 -0500 (EST) Received: from imo-d03.mx.aol.com (imo-d03.mx.aol.com [205.188.157.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03926 for ; Fri, 5 Apr 2002 08:23:23 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v32.5.) id c.10d.10121066 (661); Fri, 5 Apr 2002 08:22:44 -0500 (EST) Message-ID: <10d.10121066.29deff24@aol.com> Date: Fri, 5 Apr 2002 08:22:44 EST Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority To: jmpolk@cisco.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_10d.10121066.29deff24_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_10d.10121066.29deff24_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/4/02 6:47:09 PM Eastern Standard Time, jmpolk@cisco.com writes: > "Tele" means 'over some(long) distance(s)' -- so strictly speaking > (writing), you're correct with your intention. But most of us in this > community know there is a difference in most networks - especially in > closed networks like enterprises where most of us work - between > Telecommunications and Datacommunications. The former means "voice", the > latter means "everything else". FTP, SMTP and HTTP (3 desirable > applications from your ID) for example will always fall under the > "Datacommunications" side of this categorization, not to the > Telecommunications side. I would consider "communications" to be a better > word than "Telecom", "Datacom", "Transfer", or any others I've heard or > read or thought of. I'm looking at it to relieve confusion on limiting > focus to only voice (which you state as not being your desires here, which > I agree with BTW) > We should stick with the definition given in American National Standard T1.523-2001, which is consistent with its use by the ITU-T and ETSI (where "T" means telecommunications for both). T1.523 says: "Any transmission, emission, or reception of signs, signals, writing, images and sounds or intelligence of any nature by wire, radio, optical or other electromagnetic systems." (I suppose that, strickly speaking, smoke signals fit in this definition, since you need to see them via light wave transmission.) No, "telecommunications" does not mean just voice and any attempt to use this term as such would further confuse everyone. Lets just make sure that any reference is clear by including the right words rather than depending on everyone thinking this one word means a certain thing. (Everyone doesn''t have T1.523 in their back pocket!) Does the IETF have any agreed vocabulary document? Mike --part1_10d.10121066.29deff24_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/4/02 6:47:09 PM Eastern Standard Time, jmpolk@cisco.com writes:


"Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID)  for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on  limiting focus to only voice (which you state as not being your desires here, which I agree with BTW)


We should stick with the definition given in American National Standard T1.523-2001, which is consistent with its use by the ITU-T and ETSI (where "T" means telecommunications for both). T1.523 says:

"Any transmission, emission, or reception of signs, signals, writing, images and sounds or intelligence of any nature by wire, radio, optical or other electromagnetic systems."

(I suppose that, strickly speaking, smoke signals fit in this definition, since you need to see them via light wave transmission.)

No, "telecommunications" does not mean just voice and any attempt to use this term as such would further confuse everyone. Lets just make sure that any reference is clear by including the right words rather than depending on everyone thinking this one word means a certain thing. (Everyone doesn''t have T1.523 in their back pocket!)

Does the IETF have any agreed vocabulary document?

Mike

--part1_10d.10121066.29deff24_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 09:06:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05157 for ; Fri, 5 Apr 2002 09:06:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00916; Fri, 5 Apr 2002 08:55:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00878 for ; Fri, 5 Apr 2002 08:55:28 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04769 for ; Fri, 5 Apr 2002 08:55:23 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Apr 2002 14:55:15 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org Subject: Re: [Ieprep] We have been asked to review these drafts In-reply-to: Your message of "Mon, 18 Mar 2002 09:04:53 PST." <200203181704.JAA28015@irp-view7.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 14:55:13 +0100 Message-ID: <926.1018014913@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org howdy, > From: fred@cisco.com > Date: Mon, 18 Mar 2002 09:04:53 -0800 (PST) (17:04 GMT) > > Per our illustrious Area Director,speaking in "sipping", we need to > come up with requirements that drafts of this type would address. does our illustrius Area Director know if the authors of "SMTP Service Extension for Priority", J. Onions, G. Lunt, 05/30/2001, plan on continuing work on the draft? I see that the above expired back in November, and if its going to die off, then i'll bid it bon voyage. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 09:35:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05900 for ; Fri, 5 Apr 2002 09:35:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02276; Fri, 5 Apr 2002 09:18:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02202 for ; Fri, 5 Apr 2002 09:17:58 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05435 for ; Fri, 5 Apr 2002 09:17:53 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23607; Fri, 5 Apr 2002 09:17:24 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03336; Fri, 5 Apr 2002 09:17:25 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Apr 2002 09:17:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CDE5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Alistair Munro'" , Ken Carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] a little homily - benefits of multicast Date: Fri, 5 Apr 2002 09:17:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Yes, SIP can negotiate codecs. One end "offers" it's list of codecs, the other end "answers" with its choice(s). Transcoders are at present uncommon, and we might want to get some work done in SIP to make it a little more standardized how transcoders might be discovered and engaged. Brian > -----Original Message----- > From: Alistair Munro [mailto:alistair.munro@degree2.com] > Sent: Friday, April 05, 2002 7:58 AM > To: Ken Carlberg > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] a little homily - benefits of multicast > > > > Hi Ken, > > >I have an open ear to adding text to the current draft on > subjects it > >doesn't cover, but i'll take a very cautious approach > regarding codecs > >because i have the (possibly mis)conception that the subject really > >gets rather implementation/deployment specific. > > > Yes, I would leave people to make their own decisions on > implementation, > deployment etc. > > I was wondering if there were any issues in the interworking of > different operational networks, but decided that protocols exist to > arbitrate the selection of codecs (does SIP do this? my H.323 setup > seems happy to switch) and transcoding at boundaries is (a) done, (b) > not an issue for this WG, except possibly to remark on QoS > and bandwidth > allocation. Any comments on this will apply to video and voice. > > Regards, > > Alistair > > -- > Dr. Alistair Munro, > Chief Systems Engineer, Degree2 Innovations Ltd. > Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. > E-mail: Alistair.Munro@degree2.com > Tel: (work) +44-117-900-8114, (home) +44-1275-462707, > (mobile) +44-7974-922-442; > Fax: +44-117-900-8151 > Web: http://www.degree2.com, http://www.u4eagroup.com > > > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Fri Apr 5 11:21:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08745 for ; Fri, 5 Apr 2002 11:21:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11162; Fri, 5 Apr 2002 11:17:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11130 for ; Fri, 5 Apr 2002 11:16:59 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08565 for ; Fri, 5 Apr 2002 11:16:51 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g35GGt920310; Fri, 5 Apr 2002 11:16:55 -0500 (EST) Date: Fri, 5 Apr 2002 11:16:55 -0500 (EST) From: Scott Bradner Message-Id: <200204051616.g35GGt920310@newdev.harvard.edu> To: ieprep@ietf.org, K.Carlberg@cs.ucl.ac.uk Subject: Re: [Ieprep] We have been asked to review these drafts Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > does our illustrius Area Director know if the authors of > "SMTP Service Extension for Priority", J. Onions, G. Lunt, 05/30/2001, > > plan on continuing work on the draft? (I'll try on the "illustrius" hat) I've seen no indication that the ID was anything but an independent submission or that it git traction anywhere but I will ask Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 11:30:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08957 for ; Fri, 5 Apr 2002 11:30:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11542; Fri, 5 Apr 2002 11:29:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11510 for ; Fri, 5 Apr 2002 11:29:18 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08940 for ; Fri, 5 Apr 2002 11:29:11 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35GSXqF003610; Fri, 5 Apr 2002 08:28:41 -0800 (PST) Message-Id: <5.1.0.14.2.20020405082326.0d535fe0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 08:23:32 -0800 To: Ian Brown From: Fred Baker Subject: RE: [Ieprep] RE: Folts' stated requirements: security Cc: "Folts, Harold" , ieprep In-Reply-To: References: <5.1.0.14.2.20020404153609.0d4b3008@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 02:39 AM 4/5/2002, Ian Brown wrote: > > Could we identify someone to write that hopefully-short internet draft, > > specifying the information that AAA WG needs, and pointing to the USG > > document for further detail? > >I can write this, or add it to the security draft. please do _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 11:49:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09535 for ; Fri, 5 Apr 2002 11:49:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11584; Fri, 5 Apr 2002 11:29:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11548 for ; Fri, 5 Apr 2002 11:29:21 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08942 for ; Fri, 5 Apr 2002 11:29:14 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35GSXqH003610; Fri, 5 Apr 2002 08:28:42 -0800 (PST) Message-Id: <5.1.0.14.2.20020405082523.0d92a8e0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 08:26:11 -0800 To: Mpierce1@aol.com From: Fred Baker Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority Cc: jmpolk@cisco.com, ieprep@ietf.org In-Reply-To: <10d.10121066.29deff24@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 05:22 AM 4/5/2002, Mpierce1@aol.com wrote: >Does the IETF have any agreed vocabulary document? no. But this would be the first time I have ever heard the word "telecommunications" used to describe data communications, regardless of ANSI's definition. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 12:07:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10144 for ; Fri, 5 Apr 2002 12:07:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14379; Fri, 5 Apr 2002 12:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14302 for ; Fri, 5 Apr 2002 12:01:48 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09887 for ; Fri, 5 Apr 2002 12:01:41 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35H1Cq7021493; Fri, 5 Apr 2002 09:01:12 -0800 (PST) Message-Id: <5.1.0.14.2.20020405082657.0d5819f0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 08:28:27 -0800 To: Ken Carlberg From: Fred Baker Subject: Re: [Ieprep] We have been asked to review these drafts Cc: ieprep@ietf.org In-Reply-To: <926.1018014913@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 05:55 AM 4/5/2002, Ken Carlberg wrote: >does our illustrius Area Director know if the authors of > > "SMTP Service Extension for Priority", J. Onions, G. Lunt, 05/30/2001, > > >plan on continuing work on the draft? that would be a good question to ask the authors. It is, after all, an individual submission, not a working group document. They are: Julian Onions Graeme Lunt _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 12:35:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11086 for ; Fri, 5 Apr 2002 12:35:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15828; Fri, 5 Apr 2002 12:27:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15798 for ; Fri, 5 Apr 2002 12:27:26 -0500 (EST) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10794 for ; Fri, 5 Apr 2002 12:27:17 -0500 (EST) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4453); Fri, 5 Apr 2002 11:27:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Ieprep] clarifications about security Date: Fri, 5 Apr 2002 11:27:18 -0600 Message-ID: <16D5A1F38B010847B9C50DAF8F64EB56309887@KC-MAIL1.kc.umkc.edu> Thread-Topic: [Ieprep] clarifications about security Thread-Index: AcHcjhcT5l4ROWkZTjy2v7Mjk7TTvAAL31WQ From: "Krishnaswamy, Arvind Shankar (UMKC-Student)" To: Cc: "Ian Brown" X-OriginalArrivalTime: 05 Apr 2002 17:27:18.0504 (UTC) FILETIME=[22E3C680:01C1DCC7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15799 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit I have 2 (trivial?) questions. (1) The most significant drawback to utilizing Public Key encryption is that it is slow. Public Key encryption requires about a thousand times greater CPU time to use than does a typical Symmetric Key technique (using password). We may have to compromise on QoS because ESP(Encapsulating Security Payload) encrypts the data sent too which is computationally expensive(an IP telephony gateway relies on high-performance to maintain its quality of service). Is this compromise something which we can adjust to? (2) Proxy servers/Firewalls in IP telephony gateways can be used to maintain Access control lists to include only friendly neighbors (e.g., other gateways) so that DoS attacks can be prevented. By only recognizing friendly machines, this technique of proxy servers or firewalls is one of the most effective methods against outside intrusion on the physical system and its resources. Can this be included as a security requirement? -Arvind _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 12:53:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11509 for ; Fri, 5 Apr 2002 12:53:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17389; Fri, 5 Apr 2002 12:53:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17358 for ; Fri, 5 Apr 2002 12:53:12 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11493 for ; Fri, 5 Apr 2002 12:53:07 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA06518; Fri, 5 Apr 2002 09:52:36 -0800 (PST) Message-Id: <4.1.20020405115029.031406a8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 05 Apr 2002 11:52:06 -0600 To: Fred Baker , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority Cc: ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020405082523.0d92a8e0@mira-sjcm-4.cisco.com> References: <10d.10121066.29deff24@aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1171252502==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_1171252502==_.ALT Content-Type: text/plain; charset="us-ascii" At 08:26 AM 4/5/2002 -0800, Fred Baker wrote: >At 05:22 AM 4/5/2002, Mpierce1@aol.com wrote: >>Does the IETF have any agreed vocabulary document? > >no. But this would be the first time I have ever heard the word >"telecommunications" used to describe data communications, regardless of >ANSI's definition. that was kinda where I was coming from. it's always been separated everywhere I've been in all my past lives (jobs) > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1171252502==_.ALT Content-Type: text/html; charset="us-ascii"
At 08:26 AM 4/5/2002 -0800, Fred Baker wrote:
>At 05:22 AM 4/5/2002, Mpierce1@aol.com wrote:
>>Does the IETF have any agreed vocabulary document?
>
>no. But this would be the first time I have ever heard the word
>"telecommunications" used to describe data communications, regardless of
>ANSI's definition.

that was kinda where I was coming from. it's always been separated everywhere I've been in all my past lives (jobs)

>
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1171252502==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 14:15:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13936 for ; Fri, 5 Apr 2002 14:15:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22964; Fri, 5 Apr 2002 14:11:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22931 for ; Fri, 5 Apr 2002 14:11:16 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13820 for ; Fri, 5 Apr 2002 14:11:12 -0500 (EST) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35JAfqB007519; Fri, 5 Apr 2002 11:10:42 -0800 (PST) Message-Id: <5.1.0.14.2.20020405103410.02300df0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Apr 2002 10:56:59 -0800 To: "Krishnaswamy, Arvind Shankar (UMKC-Student)" From: Fred Baker Subject: Re: [Ieprep] clarifications about security Cc: , "Ian Brown" In-Reply-To: <16D5A1F38B010847B9C50DAF8F64EB56309887@KC-MAIL1.kc.umkc.ed u> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 09:27 AM 4/5/2002, Krishnaswamy, Arvind Shankar (UMKC-Student) wrote: >The most significant drawback to utilizing Public Key encryption is that >it is slow. Public Key encryption requires about a thousand times greater >CPU time to use than does a typical Symmetric Key technique (using password). Symmetric key encryption doesn't use a password, at least not as I understand the term. It uses a shared secret, but the secret is never exchanged on the wire. >We may have to compromise on QoS because ESP(Encapsulating Security >Payload) encrypts the data sent too which is computationally expensive(an >IP telephony gateway relies on high-performance to maintain its quality of >service). Is this compromise something which we can adjust to? As I understand it, symmetric key encryption is used with IPSEC pretty regularly; it's just not used with IKE, which is a Diffie-Hellman Public Key Exchange. >Proxy servers/Firewalls in IP telephony gateways can be used to maintain >Access control lists to include only friendly neighbors (e.g., other >gateways) so that DoS attacks can be prevented. By only recognizing >friendly machines, this technique of proxy servers or firewalls is one of >the most effective methods against outside intrusion on the physical >system and its resources. Can this be included as a security requirement? I don't think it would be wise to *require* firewalls or proxies, although they can certainly be part of the defensive solution. There are several reasons. There may not be a need for a firewall, for one thing. Taking the IM model, if instant messaging is something that always happens among a set of servers operated by the same company, there is no need for us to tell the company how to run its business. Also, firewalls do not provide security; they reduce risk. Let me give you a medical example: your body. Your body has a firewall, in the form of an organ called the "skin". It serves as a fairly effective barrier against all sorts of junk getting into your body, and reduces the risks that the rest of the immune system needs to deal with. However, anyone who thinks the skin is sufficient as a defence hasn't thought through AIDS or even the common cold. The body backs up the skin with a fairly intricate and effective intrusion detection and management system that deals with attacks on the cell level (lymphocytes), the wound level (platelets, the lymph system, and so on), and at the infection level (for example shutting down perspiration and raising the body temperature to kill a widespread infection). In the end, security is always a matter of risk reduction, and as far as I know there is no single technology that obviates the risk of internal attack as well as external attack, or addresses all attacks. What seems to be the requirement to bring out in this case is that the networks impose appropriate defences, which may include firewalls and proxies, and may well include intrusion detection systems and other mechanisms. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 14:38:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15235 for ; Fri, 5 Apr 2002 14:38:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23191; Fri, 5 Apr 2002 14:14:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23162 for ; Fri, 5 Apr 2002 14:14:25 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13887 for ; Fri, 5 Apr 2002 14:14:21 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22884; Fri, 5 Apr 2002 14:13:50 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10220; Fri, 5 Apr 2002 14:13:52 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Apr 2002 14:13:51 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CDEE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Krishnaswamy, Arvind Shankar (UMKC-Student)'" , ieprep@ietf.org Cc: Ian Brown Subject: RE: [Ieprep] clarifications about security Date: Fri, 5 Apr 2002 14:13:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > (1) > The most significant drawback to utilizing Public Key > encryption is that > it is slow. Public Key encryption requires about a thousand times > greater CPU time to use than does a typical Symmetric Key technique > (using password). > We may have to compromise on QoS because ESP(Encapsulating Security > Payload) encrypts the data sent too which is computationally > expensive(an IP telephony gateway relies on high-performance > to maintain > its quality of service). Is this compromise something which we can > adjust to? Hello? ESP would use a symmetric key (relatively fast). You could use PK to authenticate, and then use DH to negotiate the key you use for encryption. So you get one authentication and a DH PER CALL, and then use something like AES for data. HOWEVER, we are mixing several pieces of the puzzle here. For SIP based voice/video, you might use ESP for the SIP signalling channel, but you are probably better off using TLS. For the media channels, you are better off using SRTP, which encrypts the RTP, rather than encrypting at a lower layer like ESP would. The principles remain the same - PK for authentication, symmetric for bulk data (media) encryption. > > (2) > Proxy servers/Firewalls in IP telephony gateways can be used > to maintain > Access control lists to include only friendly neighbors (e.g., other > gateways) so that DoS attacks can be prevented. By only recognizing > friendly machines, this technique of proxy servers or firewalls is one > of the most effective methods against outside intrusion on > the physical > system and its resources. Can this be included as a security > requirement? Yes, you will want to rely on decent authentication mechanisms to prevent attacks. SIP has such mechanisms, although there is need for better ones. The IEPS problem presents authentication challenges such as definition of trust boundaries, cross realm authentication, and providing secure authentication in an imperfect world. For example - GETS cards are nice, but can't hold a lot of information; all you get is PIN/Password authentication. Smart cards are better, but you can't assume a smartcard reader in every device you may wish to use. We might be able to use them in VoIP phones you carry to an emergency, but I doubt that is acceptable in the general case. Tokens (SecureID) would be great, but they are too big for a wallet. There is this new implantable ID mechanism ;) Brian _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 5 16:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19942 for ; Fri, 5 Apr 2002 16:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00876; Fri, 5 Apr 2002 16:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00842 for ; Fri, 5 Apr 2002 16:51:46 -0500 (EST) Received: from imo-r07.mx.aol.com (imo-r07.mx.aol.com [152.163.225.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19937 for ; Fri, 5 Apr 2002 16:51:41 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r07.mx.aol.com (mail_out_v32.5.) id c.185.649ee1d (25511); Fri, 5 Apr 2002 16:51:03 -0500 (EST) Message-ID: <185.649ee1d.29df7647@aol.com> Date: Fri, 5 Apr 2002 16:51:03 EST Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority To: jmpolk@cisco.com, fred@cisco.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_185.649ee1d.29df7647_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_185.649ee1d.29df7647_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/5/02 12:53:02 PM Eastern Standard Time, jmpolk@cisco.com writes: > At 08:26 AM 4/5/2002 -0800, Fred Baker wrote: > >At 05:22 AM 4/5/2002, Mpierce1@aol.com wrote: > >>Does the IETF have any agreed vocabulary document? > > > >no. But this would be the first time I have ever heard the word > >"telecommunications" used to describe data communications, regardless of > >ANSI's definition. > > that was kinda where I was coming from. it's always been separated > everywhere I've been in all my past lives (jobs) > > Try these well known standards organizations, all of which deal with data as well as telephone communications: TIA Telecommunications Industry Association (which sponsors a standards committee on data transmission) ITU-T International Telecommunication Union (which has several Study Groups on data) ETSI European Telecommunications Standards Institute TTA Telecommunications Technology Association (Korea) TTC Telecommunication Technology Committee (Japan) (which has committees on things other than voice) CTIA Cellular Telecommunications and Internet Association (includes data communication) TSACC Telecommunications Standards Advisory Council of Cananda Seems everyone else is using the word in this context. Incidentally, the definition in T1.523 came directly from the previous Federal Standard 1037C, so "ANSI" didn't invent it. Mike --part1_185.649ee1d.29df7647_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/5/02 12:53:02 PM Eastern Standard Time, jmpolk@cisco.com writes:


At 08:26 AM 4/5/2002 -0800, Fred Baker wrote:
>At 05:22 AM 4/5/2002, Mpierce1@aol.com wrote:
>>Does the IETF have any agreed vocabulary document?
>
>no. But this would be the first time I have ever heard the word
>"telecommunications" used to describe data communications, regardless of
>ANSI's definition.

that was kinda where I was coming from. it's always been separated everywhere I've been in all my past lives (jobs)



Try these well known standards organizations, all of which deal with data as well as telephone communications:

TIA Telecommunications Industry Association (which sponsors a standards committee on data transmission)
ITU-T International Telecommunication Union (which has several Study Groups on data)
ETSI European Telecommunications Standards Institute
TTA Telecommunications Technology Association (Korea)
TTC Telecommunication Technology Committee (Japan) (which has committees on things other than voice)
CTIA Cellular Telecommunications and Internet Association (includes data communication)
TSACC Telecommunications Standards Advisory Council of Cananda

Seems everyone else is using the word in this context. Incidentally, the definition in T1.523 came directly from the previous Federal Standard 1037C, so "ANSI" didn't invent it.

Mike


--part1_185.649ee1d.29df7647_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 04:04:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17403 for ; Mon, 8 Apr 2002 04:04:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16808; Mon, 8 Apr 2002 03:58:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16766 for ; Mon, 8 Apr 2002 03:58:41 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17321 for ; Mon, 8 Apr 2002 03:58:34 -0400 (EDT) Received: from in-addr.btopenworld.com ([62.6.76.173] helo=degree2.com) by rhenium.btinternet.com with esmtp (Exim 3.22 #8) id 16uU2g-0004vm-00; Mon, 08 Apr 2002 08:58:23 +0100 Message-ID: <3CB14DC8.912FEC57@degree2.com> Date: Mon, 08 Apr 2002 08:59:04 +0100 From: Alistair Munro Organization: Degree2 Innovations Ltd. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: "Krishnaswamy, Arvind Shankar (UMKC-Student)" , ieprep@ietf.org, Ian Brown Subject: Re: [Ieprep] clarifications about security References: <5.1.0.14.2.20020405103410.02300df0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > >We may have to compromise on QoS because ESP(Encapsulating Security > >Payload) encrypts the data sent too which is computationally expensive(an > >IP telephony gateway relies on high-performance to maintain its quality of > >service). Is this compromise something which we can adjust to? I don't see what compromise is required. If more bits are sent then the bandwidth allocated will have to increase. If more computation is involved then terminals/forwarders/gateways will have to be more powerful. Can you explain your model of IP telephony a bit more please? In my system(s), I run a gatekeeper to place the calls, and a gateway to interwork with PSTN/ISDN. The performance I budget for depends on the number of calls I expect to handle which tends to encourage replication, not more powerful systems - gateway load can be reduced by peering and planning. This is a choice that an installer can make and budget for; it isn't a compromise. I assume that handsets will normally talk to each other directly in the IP domain, (through firewalls if they are installed), not via a relay unless there is a non-IP transit network in the way. Do we require the handsets to support additional protocols for security purposes? If so which ones? I am not sure what the current practice is for encrypting content, nor if such measures are widely implemented in typical video/voice telephony products - I'll check the ones that I am using. BTW, can we draw on the MIDCOM WG for protocols to achieve dome of this functionality? Regards, Alistair _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 09:23:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22808 for ; Mon, 8 Apr 2002 09:23:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03601; Mon, 8 Apr 2002 09:19:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03568 for ; Mon, 8 Apr 2002 09:19:38 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22719 for ; Mon, 8 Apr 2002 09:19:35 -0400 (EDT) Received: from 213.78.93.114 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Apr 2002 14:19:23 +0100 From: Ian Brown To: Alistair Munro Cc: ieprep Subject: RE: [Ieprep] clarifications about security Date: Mon, 8 Apr 2002 14:20:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CB14DC8.912FEC57@degree2.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > Do we require the handsets to support additional > protocols for security purposes? If so which ones? Most likely IPSEC/TLS for signalling protection and SRTP for content protection. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 09:40:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23268 for ; Mon, 8 Apr 2002 09:40:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05239; Mon, 8 Apr 2002 09:39:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05204 for ; Mon, 8 Apr 2002 09:39:52 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23257 for ; Mon, 8 Apr 2002 09:39:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24049; Mon, 8 Apr 2002 09:39:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06224; Mon, 8 Apr 2002 09:39:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Apr 2002 09:39:10 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57CDFB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Ian Brown'" , Alistair Munro Cc: ieprep Subject: RE: [Ieprep] clarifications about security Date: Mon, 8 Apr 2002 09:39:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org SIP already has TLS support specified. While I personally think IPSEC is more appropriate in many circumstances, and you can always deploy it if you wish, it would be best I think to stick with the TLS specs in the SIP specs. Note that SIP signalling can traverse many hops, with the media streams going directly end-to-end. TLS/IPSEC has to be applied on every hop to get security end to end. There is a spec about that, but you understand that it's easy to lie about such a chain of trust associations. There is an S/MIME based end-to-end scheme when you really need some information held confidential end-to-end. As a practical matter, anything that is needed to route a message has to be examined by intermediate entities (SIP Proxy Servers) and thus usually cannot be encrypted by the S/MIME mechanisms. The hop-by-hop techniques using TLS (or IPSEC) do work for that. The TLS mechanisms are mandatory-to-implement for proxy servers. However, they may not be enabled at all the intermediaries you may encounter in an emergency. Carefull attention to what is placed in which headers, and judicious use of the S/MIME mechanism should allow a sufficiently robust confidentiality environment. I agree than SRTP is what we want for the media streams. Brian > -----Original Message----- > From: Ian Brown [mailto:I.Brown@cs.ucl.ac.uk] > Sent: Monday, April 08, 2002 9:20 AM > To: Alistair Munro > Cc: ieprep > Subject: RE: [Ieprep] clarifications about security > > > > Do we require the handsets to support additional > > protocols for security purposes? If so which ones? > > Most likely IPSEC/TLS for signalling protection and SRTP for content > protection. > > > _______________________________________________ > 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 From ieprep-admin@ietf.org Mon Apr 8 10:37:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25350 for ; Mon, 8 Apr 2002 10:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09784; Mon, 8 Apr 2002 10:32:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09746 for ; Mon, 8 Apr 2002 10:32:02 -0400 (EDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25196 for ; Mon, 8 Apr 2002 10:31:59 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2QGM1TYQ>; Mon, 8 Apr 2002 10:32:02 -0400 Message-ID: <1AE13ACECA51D511BA5600204804EE4A8D73BB@rbmail102.chamb.disa.mil> From: "Perschau, Stephen" To: "'Hal Folts'" , "Gunn, Janet NE" Cc: ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority Date: Mon, 8 Apr 2002 10:31:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF0A.244B0D90" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF0A.244B0D90 Content-Type: text/plain; charset="ISO-8859-1" Here are the definitions for telecommunications our Convergence Working Group (Established by the NSC) used. I do not believe that either definition limits telecommunications to just "voice" "The term "telecommunications" is defined by the OSTP and the NSC regulations as: "{A}ny transmission, emission, or reception of signs, signals, writing, images, graphics, and sounds or intelligence of any nature by wire, radio, optical or other electronic means" (47 CFR 201.2[k]). The definition of telecommunications used by the Federal Communications Commission (FCC) differs somewhat: i.e., "the transmission, between and among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received" (47 U.S.C. Sec. 153 [43])." -----Original Message----- From: Hal Folts [mailto:capthal@attglobal.net] Sent: Thursday, April 04, 2002 8:34 PM To: Gunn, Janet NE Cc: ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of Gunn, Janet NE Sent: Thursday, April 04, 2002 7:43 PM To: 'James M. Polk'; ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority I've also worked with people who used "telecommunications" to mean "data communications" (including the LAN, which annoyed the h&** out of me) and "telephony" to mean voice. I think the usage is very non-standardized, and whatever we decide, SOMEONE will think we meant something different. Janet, where have you been. I have been in the telecommunications business for over forty years now and the definition is very clear. Telecommunications is a means of conveying communications and information via electrical means, including telegraphy, data communications, wireless, telephony, etc. Let's not try to be clever and try to define new terms. Telecommunications is not restricted to voice only. Data Communications is a subset of telecommunications. The ITU International Telecommunication Union was founded in 1863 when Marconi started to send radio waves and morse invented his code. Let's not waste anymore time on this issue!! -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, April 04, 2002 6:45 PM To: ieprep@ietf.org Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote: -----Original Message----- From: James M. Polk [ mailto:jmpolk@cisco.com ] Sent: Monday, March 25, 2002 1:24 PM To: ieprep@ietf.org Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: Ken, I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS. I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses) [HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure. "Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID) for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on limiting focus to only voice (which you state as not being your desires here, which I agree with BTW) Hal ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1DF0A.244B0D90 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Here are the=20 definitions for telecommunications our Convergence Working Group=20 (Established by the NSC) used.  I do not believe that either = definition=20 limits telecommunications to just "voice"
 
"The term = “telecommunications” is defined by the=20 OSTP and the NSC regulations as: “{A}ny=20 transmission, emission, or reception of signs, signals, writing, = images,=20 graphics, and sounds or intelligence of any nature by wire, radio, = optical or=20 other electronic means” (47 CFR 201.2[k]).  The definition of = telecommunications=20 used by the Federal Communications Commission (FCC) differs somewhat: = i.e., “the transmission, between and = among points=20 specified by the user, of information of the user’s choosing, = without change in=20 the form or content of the information as sent and received” = (47 U.S.C. Sec.=20 153 [43])."
-----Original Message-----
From: Hal Folts=20 [mailto:capthal@attglobal.net]
Sent: Thursday, April 04, = 2002 8:34=20 PM
To: Gunn, Janet NE
Cc:=20 ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" priority = value for=20 Resource-Priority

-----Original = Message-----
From:=20 ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of = Gunn,=20 Janet NE
Sent: Thursday, April 04, 2002 7:43 = PM
To: 'James=20 M. Polk'; ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" = priority=20 value for Resource-Priority

I've also worked with people who used "telecommunications" = to mean=20 "data communications" (including the LAN, which annoyed the = h&** out of=20 me) and "telephony" to mean voice. 
 
I think the usage is very = non-standardized, and=20 whatever we decide, SOMEONE will think we meant something = different. 
 =
Janet, where have=20 you been. I have been in the telecommunications business for over = forty=20 years now and the definition is very clear. = Telecommunications is a=20 means of conveying communications and information via electrical = means,=20 including telegraphy, data communications, wireless, telephony, = etc. Let's=20 not try to be clever and try to define new terms.  = Telecommunications=20 is not restricted to voice only. Data Communications is a subset of = telecommunications. The ITU International Telecommunication Union = was=20 founded in 1863 when Marconi started to send radio waves and morse = invented=20 his code. Let's not waste anymore time on this=20 issue!!
-----Original Message-----
From: James M. Polk = [mailto:jmpolk@cisco.com]
Sent: Thursday, April 04, = 2002 6:45=20 PM
To: ieprep@ietf.org
Subject: RE: [Ieprep] = "IEPREP"=20 priority value for Resource-Priority

At 01:04 = PM=20 4/4/2002 -0500, Folts, Harold wrote:
-----Original = Message-----
From:=20 James M. Polk [mailto:jmpolk@cisco.com]
Sent: = Monday,=20 March 25, 2002 1:24 PM
To: = ieprep@ietf.org
Subject:=20 Re: [Ieprep] "IEPREP" priority value for = Resource-Priority
At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman = wrote:=20
Ken,

I believe that Hal is now using the term ETS = (Emergency=20 Telecommunications Service) rather than ECS. =
I have an issue with this change in view of the IEPREP = Charter=20 addressing more than Voice (ie Telecommunications) -- and = of the two=20 then prefer ECS (which could mean anything from Voice to IM = to FTP=20 to HTTP to whatever IAA uses)



[HF] The term "communication is too general and can = include=20 postal service and smoke signals. Telecommunications is = appropriate=20 and should not be limited to voice or telephony. I consider = telecom.=20 to apply equally to the Internet and all modes in a network = infrastructure.

"Tele" means 'over some(long) distance(s)' -- so = strictly=20 speaking (writing), you're correct with your intention. But most = of us in=20 this community know there is a difference in most networks - = especially in=20 closed networks like enterprises where most of us work - between=20 Telecommunications and Datacommunications. The former means = "voice", the=20 latter means "everything else". FTP, SMTP and HTTP (3 desirable=20 applications from your ID)  for example will always fall = under the=20 "Datacommunications" side of this categorization, not to the=20 Telecommunications side. I would consider "communications" to be = a better=20 word than "Telecom", "Datacom", "Transfer", or any others I've = heard or=20 read or thought of. I'm looking at it to relieve confusion = on =20 limiting focus to only voice (which you state as not being your = desires=20 here, which I agree with BTW)
Hal


*************************************
"People=20 generally demand more respect for their own rights than they = are willing=20 to allow for others"

James M. Polk
Consulting=20 Engineer
Office of the CTO

Cisco Systems
2200 East = President George Bush Turnpike
Richardson, TX  75082 = USA
w)=20 972.813.5208
f)  972.813.5280
www.cisco.com=20
------_=_NextPart_001_01C1DF0A.244B0D90-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 10:49:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25808 for ; Mon, 8 Apr 2002 10:49:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11156; Mon, 8 Apr 2002 10:48:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11115 for ; Mon, 8 Apr 2002 10:48:33 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25771 for ; Mon, 8 Apr 2002 10:48:29 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA02005; Mon, 8 Apr 2002 07:48:21 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA20729; Mon, 8 Apr 2002 07:48:12 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g38EmBt17064; Mon, 8 Apr 2002 07:48:11 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <22H8YG4V>; Mon, 8 Apr 2002 07:48:10 -0700 Message-ID: <48AB069E90AC6F4B9085EE3BF6E8F51B05C0B4F0@xch-blv-08.nw.nos.boeing.com> From: "Russert, Steven W" To: "'Rosen, Brian'" Cc: ieprep Subject: RE: [Ieprep] clarifications about security Date: Mon, 8 Apr 2002 07:48:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Brian, IPSEC has two modes - the "tunnel" mode secures traffic between two network devices as you state below, but the "transport" mode sets up a secure session between two endpoints. Thus, the IPSEC session has only to be set up once (in that mode). Regards, Steve Russert -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Monday, April 08, 2002 6:39 AM To: 'Ian Brown'; Alistair Munro Cc: ieprep Subject: RE: [Ieprep] clarifications about security SIP already has TLS support specified. While I personally think IPSEC is more appropriate in many circumstances, and you can always deploy it if you wish, it would be best I think to stick with the TLS specs in the SIP specs. Note that SIP signalling can traverse many hops, with the media streams going directly end-to-end. TLS/IPSEC has to be applied on every hop to get security end to end. There is a spec about that, but you understand that it's easy to lie about such a chain of trust associations. There is an S/MIME based end-to-end scheme when you really need some information held confidential end-to-end. As a practical matter, anything that is needed to route a message has to be examined by intermediate entities (SIP Proxy Servers) and thus usually cannot be encrypted by the S/MIME mechanisms. The hop-by-hop techniques using TLS (or IPSEC) do work for that. The TLS mechanisms are mandatory-to-implement for proxy servers. However, they may not be enabled at all the intermediaries you may encounter in an emergency. Carefull attention to what is placed in which headers, and judicious use of the S/MIME mechanism should allow a sufficiently robust confidentiality environment. I agree than SRTP is what we want for the media streams. Brian > -----Original Message----- > From: Ian Brown [mailto:I.Brown@cs.ucl.ac.uk] > Sent: Monday, April 08, 2002 9:20 AM > To: Alistair Munro > Cc: ieprep > Subject: RE: [Ieprep] clarifications about security > > > > Do we require the handsets to support additional > > protocols for security purposes? If so which ones? > > Most likely IPSEC/TLS for signalling protection and SRTP for content > protection. > > > _______________________________________________ > 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 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 11:42:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27413 for ; Mon, 8 Apr 2002 11:42:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15017; Mon, 8 Apr 2002 11:35:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14978 for ; Mon, 8 Apr 2002 11:35:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27203 for ; Mon, 8 Apr 2002 11:35:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05577; Mon, 8 Apr 2002 11:01:31 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02213; Mon, 8 Apr 2002 11:01:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Apr 2002 11:01:31 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57CE00@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Russert, Steven W'" Cc: ieprep Subject: RE: [Ieprep] clarifications about security Date: Mon, 8 Apr 2002 11:01:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Yes, I know that, and either could be established without any SIP applications knowing it was there on a particular hop. The problem is, in an emergency, how does a user know if his SIP message sequence is private from end to end? SIP messages may traverse several proxy servers. The first hop (from the user's device to the first proxy) could be known to the user in some circumstances, but in many emergency circumstances, you can't assume that the network you are plugging into has IPSEC available for an arbitrary device plugged in. Even if you could, the next hop may not be so protected, and you have no way of knowing. Tunnelling through a network to get to a secure proxy server is possible, but in general, I think most scenarios have to assume that existing proxy servers will be needed to correctly route messages. If that's not the case, then you could have a SIP device that had an IPSEC implementation, that tunneled through an unknown network, to get to a known (and secure) network. In that instance, IPSEC is useful. Of course, the TLS implementation that is provided for in the specs would also work. Of course, many firewalls would stop you as presently configured. Brian > -----Original Message----- > From: Russert, Steven W [mailto:steven.w.russert@boeing.com] > Sent: Monday, April 08, 2002 10:48 AM > To: 'Rosen, Brian' > Cc: ieprep > Subject: RE: [Ieprep] clarifications about security > > > Brian, > IPSEC has two modes - the "tunnel" mode secures traffic > between two > network devices as you state below, but the "transport" mode sets up a > secure session between two endpoints. Thus, the IPSEC > session has only to > be set up once (in that mode). > Regards, > Steve Russert > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, April 08, 2002 6:39 AM > To: 'Ian Brown'; Alistair Munro > Cc: ieprep > Subject: RE: [Ieprep] clarifications about security > > > SIP already has TLS support specified. While I personally think > IPSEC is more appropriate in many circumstances, and you can > always deploy it if you wish, it would be best I think to > stick with the TLS specs in the SIP specs. > > Note that SIP signalling can traverse many hops, with the media > streams going directly end-to-end. TLS/IPSEC has to be applied > on every hop to get security end to end. There is a spec about > that, but you understand that it's easy to lie about such a > chain of trust associations. There is an S/MIME based end-to-end > scheme when you really need some information held confidential > end-to-end. As a practical matter, anything that is needed to > route a message has to be examined by intermediate entities (SIP > Proxy Servers) and thus usually cannot be encrypted by the S/MIME > mechanisms. The hop-by-hop techniques using TLS (or IPSEC) do > work for that. > > The TLS mechanisms are mandatory-to-implement for proxy servers. > However, they may not be enabled at all the intermediaries you > may encounter in an emergency. Carefull attention to what is > placed in which headers, and judicious use of the S/MIME mechanism > should allow a sufficiently robust confidentiality environment. > > I agree than SRTP is what we want for the media streams. > > Brian > > > -----Original Message----- > > From: Ian Brown [mailto:I.Brown@cs.ucl.ac.uk] > > Sent: Monday, April 08, 2002 9:20 AM > > To: Alistair Munro > > Cc: ieprep > > Subject: RE: [Ieprep] clarifications about security > > > > > > > Do we require the handsets to support additional > > > protocols for security purposes? If so which ones? > > > > Most likely IPSEC/TLS for signalling protection and SRTP for content > > protection. > > > > > > _______________________________________________ > > 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 > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 8 11:50:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27684 for ; Mon, 8 Apr 2002 11:50:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16209; Mon, 8 Apr 2002 11:47:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16172 for ; Mon, 8 Apr 2002 11:47:29 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27553 for ; Mon, 8 Apr 2002 11:47:25 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g38Fkmq7020676; Mon, 8 Apr 2002 08:46:48 -0700 (PDT) Message-Id: <5.1.0.14.2.20020408084421.0511fe20@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Apr 2002 08:46:40 -0700 To: Alistair Munro From: Fred Baker Subject: Re: [Ieprep] clarifications about security Cc: "Krishnaswamy, Arvind Shankar (UMKC-Student)" , ieprep@ietf.org, Ian Brown In-Reply-To: <3CB14DC8.912FEC57@degree2.com> References: <5.1.0.14.2.20020405103410.02300df0@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:59 AM 4/8/2002, Alistair Munro wrote: >I am not sure what the current >practice is for encrypting content there are two cases: one can encrypt a call, or one can encrypt the traffic going to a target system, as in the case of a VPN. They are rather different. In either case, any QoS procedures need to minimize the delay in transmitting the voice, by some combination of shaping and queuing. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 10 06:50:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15044 for ; Wed, 10 Apr 2002 06:50:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12787; Wed, 10 Apr 2002 06:50:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12750 for ; Wed, 10 Apr 2002 06:50:07 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15033 for ; Wed, 10 Apr 2002 06:50:03 -0400 (EDT) Received: from 213.78.90.194 by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Apr 2002 11:49:44 +0100 From: Ian Brown To: ieprep Subject: Re: [Ieprep] We have been asked to review these drafts Date: Wed, 10 Apr 2002 11:50:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Fred said: >Per our illustrious Area Director,speaking in "sipping", we need to >come up with requirements that drafts of this type would address. The >requirements should not be of the form "someone has decided that this >should be done in their private network", but rather "there is a strong >technical need for this to be done in any IP network, for specific >reasons demonstrated by user practice or simulation results." > > "SMTP Service Extension for Priority", J. Onions, G. Lunt, 05/30/2001, > I have some comments on this draft, but I'll save them until people with more SMTP server operational experience than I have comment on whether they think a priority ESMTP option would be useful... I can see that it might be useful in allowing the following types of behaviour: * Deliver prioritised messages before "normal" messages (but do SMTP servers ever build up significant queues of messages?) * Retry delivery of prioritised messages more often than normal messages if the first attempt fails * Refuse to accept prioritised messages from users if the resources aren't available to do priority delivery? What do people think? Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 10 07:46:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15646 for ; Wed, 10 Apr 2002 07:46:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15339; Wed, 10 Apr 2002 07:46:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15292 for ; Wed, 10 Apr 2002 07:46:26 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15642 for ; Wed, 10 Apr 2002 07:46:22 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Apr 2002 12:46:11 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Ian Brown cc: ieprep Subject: Re: [Ieprep] We have been asked to review these drafts In-reply-to: Your message of "Wed, 10 Apr 2002 11:50:44 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Apr 2002 12:46:12 +0100 Message-ID: <912.1018439172@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > * Deliver prioritised messages before "normal" messages (but do SMTP servers > ever build up significant queues of messages?) its quite dependent on the configuration & deployment at a given site, but for large enterprise networks, yes, on occasion they do tend to suffer from these build ups. viruses like Melissa are the usual culprits that folks blame when thinking about the topic, but some of the larger businesses also ask their employees to not (re)distribute the animated email christmas cards because of the culmulative buffer space they consume and the ripple effect they generate in slowing down delivery of regular business email. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 10 11:31:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22378 for ; Wed, 10 Apr 2002 11:31:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28375; Wed, 10 Apr 2002 11:22:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28340 for ; Wed, 10 Apr 2002 11:22:49 -0400 (EDT) Received: from kdmd.net (adsl-64-160-215-222.dsl.frsn01.pacbell.net [64.160.215.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22084 for ; Wed, 10 Apr 2002 11:22:38 -0400 (EDT) Received: from GW-KDMD-Message_Server by kdmd.net with Novell_GroupWise; Wed, 10 Apr 2002 08:22:40 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 10 Apr 2002 08:22:27 -0500 From: "Ken Diliberto" To: Subject: Re: [Ieprep] We have been asked to review these drafts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA28341 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit In my mind, a disaster means down communications and such. I would think that would cause congestion by itself. The other Ken :-) >>> Ken Carlberg 04/10/02 06:46AM >>> > * Deliver prioritised messages before "normal" messages (but do SMTP servers > ever build up significant queues of messages?) its quite dependent on the configuration & deployment at a given site, but for large enterprise networks, yes, on occasion they do tend to suffer from these build ups. viruses like Melissa are the usual culprits that folks blame when thinking about the topic, but some of the larger businesses also ask their employees to not (re)distribute the animated email christmas cards because of the culmulative buffer space they consume and the ripple effect they generate in slowing down delivery of regular business email. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 10 12:54:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25074 for ; Wed, 10 Apr 2002 12:53:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04885; Wed, 10 Apr 2002 12:51:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04853 for ; Wed, 10 Apr 2002 12:50:53 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25027 for ; Wed, 10 Apr 2002 12:50:50 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA27207; Wed, 10 Apr 2002 09:50:07 -0700 (PDT) Message-Id: <4.1.20020410113112.02d8ce10@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Apr 2002 11:50:05 -0500 To: "Perschau, Stephen" , "'Hal Folts'" , "Gunn, Janet NE" From: "James M. Polk" Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority Cc: ieprep@ietf.org In-Reply-To: <1AE13ACECA51D511BA5600204804EE4A8D73BB@rbmail102.chamb.dis a.mil> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_157288629==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_157288629==_.ALT Content-Type: text/plain; charset="us-ascii" Stephen At 10:31 AM 4/8/2002 -0400, Perschau, Stephen wrote: > > Here are the definitions for telecommunications our Convergence Working Group > (Established by the NSC) used. I do not believe that either definition > limits telecommunications to just "voice" > > "The term telecommunications is defined by the OSTP and the NSC regulations > as: {A}ny transmission, emission, or reception of signs, signals, writing, > images, graphics, and sounds or intelligence of any nature by wire, radio, > optical or other electronic means (47 CFR 201.2[k]). Does this include Cable TV transmission and reception from a company like Cox or Cablevision? What about Satellite transmission and reception like DirecTV and Dish? Does this include the copying of an existing VCR tape to another VCR tape in another Recorder unit? > > The definition of telecommunications used by the Federal Communications > Commission (FCC) differs somewhat: i.e., the transmission, between and among > points specified by the user, of information of the user s choosing, without > change in the form or content of the information as sent and received (47 > U.S.C. Sec. 153 [43])." This would literally not omit smoke signals as telecommunications... or talking through air without electrical mediums in between... or a user sending a print job to their serial attached printer from their standalone (as in not connected to the Internet and has no modem) computer... wouldn't this also include a user burning CD-R copy of anything in that burner is external to the computer? I don't mean to be funny, but the above examples are used my most every day and I just want to know what the bounds are of the definition of Telecommunications, because it appears to me that since Telecommunications was early in organization, most organizations involved in what I consider normal voice transmission over some distance merely included (seemingly) everything else and no one really told them they couldn't. I'd thing it'd be hard to get too many people to agree that the NBC broadcast of "West Wing" or "Friends" either over the airwaves or via Cable TV connect as Telecommunications; equally true about printing to a locally attached printer from a standalone PC.... > >> >> -----Original Message----- >> From: Hal Folts [mailto:capthal@attglobal.net] >> Sent: Thursday, April 04, 2002 8:34 PM >> To: Gunn, Janet NE >> Cc: ieprep@ietf.org >> Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority >> >> -----Original Message----- >> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of Gunn, >> Janet NE >> Sent: Thursday, April 04, 2002 7:43 PM >> To: 'James M. Polk'; ieprep@ietf.org >> Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority >> >> I've also worked with people who used "telecommunications" to mean "data >> communications" (including the LAN, which annoyed the h&** out of me) and >> "telephony" to mean voice. >> >> I think the usage is very non-standardized, and whatever we decide, SOMEONE >> will think we meant something different. >> >> Janet, where have you been. I have been in the telecommunications business >> for over forty years now and the definition is very clear. >> Telecommunications is a means of conveying communications and information >> via electrical means, including telegraphy, data communications, wireless, >> telephony, etc. Let's not try to be clever and try to define new terms. >> Telecommunications is not restricted to voice only. Data Communications is a >> subset of telecommunications. The ITU International Telecommunication Union >> was founded in 1863 when Marconi started to send radio waves and morse >> invented his code. Let's not waste anymore time on this issue!! >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Thursday, April 04, 2002 6:45 PM >> To: ieprep@ietf.org >> Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority >> >> At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote: >>> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Monday, March 25, 2002 1:24 PM >>> To: ieprep@ietf.org >>> Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority >>> At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote: >>>> >>>> Ken, >>>> >>>> I believe that Hal is now using the term ETS (Emergency Telecommunications >>>> Service) rather than ECS. >>> >>> I have an issue with this change in view of the IEPREP Charter addressing >>> more than Voice (ie Telecommunications) -- and of the two then prefer ECS >>> (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA >>> uses) >>> >>> >>> >>> [HF] The term "communication is too general and can include postal service >>> and smoke signals. Telecommunications is appropriate and should not be >>> limited to voice or telephony. I consider telecom. to apply equally to the >>> Internet and all modes in a network infrastructure. >> >> >> "Tele" means 'over some(long) distance(s)' -- so strictly speaking >> (writing), you're correct with your intention. But most of us in this >> community know there is a difference in most networks - especially in closed >> networks like enterprises where most of us work - between Telecommunications >> and Datacommunications. The former means "voice", the latter means >> "everything else". FTP, SMTP and HTTP (3 desirable applications from your >> ID) for example will always fall under the "Datacommunications" side of >> this categorization, not to the Telecommunications side. I would consider >> "communications" to be a better word than "Telecom", "Datacom", "Transfer", >> or any others I've heard or read or thought of. I'm looking at it to relieve >> confusion on limiting focus to only voice (which you state as not being >> your desires here, which I agree with BTW) >>> >>> Hal >> >> >> >> ************************************* >> "People generally demand more respect for their own rights than they are >> willing to allow for others" >> >> James M. Polk >> Consulting Engineer >> Office of the CTO >> >> Cisco Systems >> 2200 East President George Bush Turnpike >> Richardson, TX 75082 USA >> w) 972.813.5208 >> f) 972.813.5280 >> www.cisco.com > > > > ************************************* > "People generally demand more respect for their own rights than they are > willing to allow for others" > > James M. Polk > Consulting Engineer > Office of the CTO > > Cisco Systems > 2200 East President George Bush Turnpike > Richardson, TX 75082 USA > w) 972.813.5208 > f) 972.813.5280 > www.cisco.com --=====================_157288629==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephen

At 10:31 AM 4/8/2002 -0400, Perschau, Stephen wrote:
Here are the definitions for telecommunications our Convergence Working Group (Established by the NSC) used.  I do not believe that either definition limits telecommunications to just "voice"
 
"The term telecommunications is defined by the OSTP and the NSC regulations as: {A}ny transmission, emission, or reception of signs, signals, writing, images, graphics, and sounds or intelligence of any nature by wire, radio, optical or other electronic means (47 CFR 201.2[k]). 

Does this include Cable TV transmission and reception from a company like Cox or Cablevision? What about Satellite transmission and reception like DirecTV and Dish? Does this include the copying of an existing VCR tape to another VCR tape in another Recorder unit?

The definition of telecommunications used by the Federal Communications Commission (FCC) differs somewhat: i.e., the transmission, between and among points specified by the user, of information of the user s choosing, without change in the form or content of the information as sent and received (47 U.S.C. Sec. 153 [43])."

This would literally not omit smoke signals as telecommunications... or talking through air without electrical mediums in between... or a user sending a print job to their serial attached printer from their standalone (as in not connected to the Internet and has no modem) computer... wouldn't this also include a user burning CD-R copy of anything in that burner is external to the computer?

I don't mean to be funny, but the above examples are used my most every day and I just want to know what the bounds are of the definition of Telecommunications, because it appears to me that since Telecommunications was early in organization, most organizations involved in what I consider normal voice transmission over some distance merely included (seemingly) everything else and no one really told them they couldn't.

I'd thing it'd be hard to get too many people to agree that the NBC broadcast of "West Wing" or "Friends" either over the airwaves or via Cable TV connect as Telecommunications; equally true about printing to a locally attached printer from a standalone PC....
-----Original Message-----
From: Hal Folts [mailto:capthal@attglobal.net]
Sent: Thursday, April 04, 2002 8:34 PM
To: Gunn, Janet NE
Cc: ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority

-----Original Message-----
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of Gunn, Janet NE
Sent: Thursday, April 04, 2002 7:43 PM
To: 'James M. Polk'; ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority
I've also worked with people who used "telecommunications" to mean "data communications" (including the LAN, which annoyed the h&** out of me) and "telephony" to mean voice. 
 
I think the usage is very non-standardized, and whatever we decide, SOMEONE will think we meant something different.
 
Janet, where have you been. I have been in the telecommunications business for over forty years now and the definition is very clear. Telecommunications is a means of conveying communications and information via electrical means, including telegraphy, data communications, wireless, telephony, etc. Let's not try to be clever and try to define new terms.  Telecommunications is not restricted to voice only. Data Communications is a subset of telecommunications. The ITU International Telecommunication Union was founded in 1863 when Marconi started to send radio waves and morse invented his code. Let's not waste anymore time on this issue!!
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Thursday, April 04, 2002 6:45 PM
To: ieprep@ietf.org
Subject: RE: [Ieprep] "IEPREP" priority value for Resource-Priority
At 01:04 PM 4/4/2002 -0500, Folts, Harold wrote:
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Monday, March 25, 2002 1:24 PM
To: ieprep@ietf.org
Subject: Re: [Ieprep] "IEPREP" priority value for Resource-Priority
At 04:06 AM 3/25/2002 -0700, Stuart (Stu) Goldman wrote:
Ken,

I believe that Hal is now using the term ETS (Emergency Telecommunications Service) rather than ECS.
I have an issue with this change in view of the IEPREP Charter addressing more than Voice (ie Telecommunications) -- and of the two then prefer ECS (which could mean anything from Voice to IM to FTP to HTTP to whatever IAA uses)



[HF] The term "communication is too general and can include postal service and smoke signals. Telecommunications is appropriate and should not be limited to voice or telephony. I consider telecom. to apply equally to the Internet and all modes in a network infrastructure.

"Tele" means 'over some(long) distance(s)' -- so strictly speaking (writing), you're correct with your intention. But most of us in this community know there is a difference in most networks - especially in closed networks like enterprises where most of us work - between Telecommunications and Datacommunications. The former means "voice", the latter means "everything else". FTP, SMTP and HTTP (3 desirable applications from your ID)  for example will always fall under the "Datacommunications" side of this categorization, not to the Telecommunications side. I would consider "communications" to be a better word than "Telecom", "Datacom", "Transfer", or any others I've heard or read or thought of. I'm looking at it to relieve confusion on  limiting focus to only voice (which you state as not being your desires here, which I agree with BTW)
Hal=20


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_157288629==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 11 03:15:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21261 for ; Thu, 11 Apr 2002 03:15:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27491; Thu, 11 Apr 2002 02:51:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27455 for ; Thu, 11 Apr 2002 02:50:54 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20923 for ; Thu, 11 Apr 2002 02:50:50 -0400 (EDT) Received: from degree2.com (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g3B6oh712472; Thu, 11 Apr 2002 07:50:43 +0100 Message-ID: <3CB53346.1080905@degree2.com> Date: Thu, 11 Apr 2002 07:55:02 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Folts, Harold" CC: ieprep@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ieprep] What next?, getting to the BCP deliverable. Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Hal, Finding myself becalmed in an airport again, I have been through the drafts from Fred, yourself and Ken C. a few more times. I was wondering how to move forward. From my point of view, there are two things I need: functional/service requirements from the ETS side (your draft), and solutions from the IP side (Fred's draft). I like very much your A. - K paragraphs in section 4 as a list of requirements for the ETS - this is my interpretation at least, I don't know if others see it that way. Would it be a good idea to add a list of solutions to each, based roughly on Fred's draft plus some the results of current discussions, plus additions where topics aren't covered (Ken's document contains some useful stuff), aiming for the BCP deliverable? If this is blindingly obvious, please excuse me. However, I would like to start making some real contributions, and I also need to plan for getting solutions out of other WGs where they are (apparently) missing. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.degree2.com, http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 11 14:43:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09137 for ; Thu, 11 Apr 2002 14:43:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03919; Thu, 11 Apr 2002 14:15:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03887 for ; Thu, 11 Apr 2002 14:15:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08285 for ; Thu, 11 Apr 2002 14:15:13 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3BIEdq6009897; Thu, 11 Apr 2002 11:14:39 -0700 (PDT) Received: from SKEAGY-W2K1.cisco.com (dhcp-171-69-95-28.cisco.com [171.69.95.28]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA25702; Thu, 11 Apr 2002 11:14:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20020411110342.01728c00@malone.cisco.com> X-Sender: skeagy@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Apr 2002 11:14:38 -0700 To: Ian Brown , ieprep From: Scott Keagy Subject: Re: [Ieprep] We have been asked to review these drafts In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org comment on email queues in-line.... At 11:50 AM 4/10/2002 +0100, Ian Brown wrote: >Fred said: > >Per our illustrious Area Director,speaking in "sipping", we need to > >come up with requirements that drafts of this type would address. The > >requirements should not be of the form "someone has decided that this > >should be done in their private network", but rather "there is a strong > >technical need for this to be done in any IP network, for specific > >reasons demonstrated by user practice or simulation results." > > > > "SMTP Service Extension for Priority", J. Onions, G. Lunt, 05/30/2001, > > > >I have some comments on this draft, but I'll save them until people with >more SMTP server operational experience than I have comment on whether they >think a priority ESMTP option would be useful... I can see that it might be >useful in allowing the following types of behaviour: > >* Deliver prioritised messages before "normal" messages (but do SMTP servers >ever build up significant queues of messages?) Depends on how the mail administrator configures the network. For example "sendmail -bd -q30m" will cause the mail server to queue mail for 30 minutes before sending (at least that's what I distantly remember from my mailserver days). In this case, would need a separate queue for prioritized messages (and maybe a command-line option to specify the priority queue processing interval). Other consideration: will Blackberry and other 2-way pagers latch onto this for better performance of email messages, at the risk of emergency traffic? If so, will need do distinguish emergency messages versus normal messages requesting low latency. Regards, Scott >* Retry delivery of prioritised messages more often than normal messages if >the first attempt fails > >* Refuse to accept prioritised messages from users if the resources aren't >available to do priority delivery? > >What do people think? > >Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 12 06:27:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02766 for ; Fri, 12 Apr 2002 06:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05613; Fri, 12 Apr 2002 06:03:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05581 for ; Fri, 12 Apr 2002 06:03:41 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00352 for ; Fri, 12 Apr 2002 06:03:37 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <2QGMBQQ8>; Fri, 12 Apr 2002 06:03:40 -0400 Message-ID: From: "Folts, Harold" To: "'Alistair Munro'" Cc: ieprep@ietf.org Date: Fri, 12 Apr 2002 06:03:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: What next?, getting to the BCP deliverable. Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Alistair Munro [mailto:alistair.munro@degree2.com] > Sent: Thursday, April 11, 2002 2:55 AM > To: Folts, Harold > Cc: ieprep@ietf.org > Subject: What next?, getting to the BCP deliverable. > > > Hi Hal, > > Finding myself becalmed in an airport again, I have been through the > drafts from Fred, yourself and Ken C. a few more times. I was > wondering > how to move forward. From my point of view, there are two > things I need: > functional/service requirements from the ETS side (your draft), and > solutions from the IP side (Fred's draft). I like very much > your A. - K > paragraphs in section 4 as a list of requirements for the ETS > - this is > my interpretation at least, I don't know if others see it that way. > Would it be a good idea to add a list of solutions to each, based > roughly on Fred's draft plus some the results of current discussions, > plus additions where topics aren't covered (Ken's document > contains some > useful stuff), aiming for the BCP deliverable? > Alistair, That list of A-K eleven requirements seems to have been well agreed upon in all the groups that I work with. There have been no suggestions to expand it so far, but I am always open to additional thoughts. I agree that the next step should be to fill in solutions for each. Not all items have been addressed yet, but many are being worked in a number of standards development groups including the IETF. Your input and contribution to this will be most welcome. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 10:23:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19876 for ; Wed, 17 Apr 2002 10:23:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12838; Wed, 17 Apr 2002 10:22:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12793 for ; Wed, 17 Apr 2002 10:22:20 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19543 for ; Wed, 17 Apr 2002 10:22:15 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA19481; Wed, 17 Apr 2002 07:21:32 -0700 (PDT) Message-Id: <4.1.20020417090804.01548178@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Apr 2002 09:21:30 -0500 To: "Rosen, Brian" , "'Alistair Munro'" , Ken Carlberg From: "James M. Polk" Subject: RE: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF57CDE5@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_65020875==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_65020875==_.ALT Content-Type: text/plain; charset="us-ascii" At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote: >Transcoders are at present uncommon, huh? We build several products that do this function by design -- and have for more than 2 (3?) years >and we might want to >get some work done in SIP to make it a little more standardized >how transcoders might be discovered and engaged. I would agree with this statement, but this is more a function of a Server in the route maybe causing a redirect to a known transcoder (like a conference) of that Server ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_65020875==_.ALT Content-Type: text/html; charset="us-ascii"
At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote:

>Transcoders are at present uncommon,

huh? We build several products that do this function by design -- and have for more than 2 (3?) years

>and we might want to
>get some work done in SIP to make it a little more standardized
>how transcoders might be discovered and engaged.

I would agree with this statement, but this is more a function of a Server in the route maybe causing a redirect to a known transcoder (like a conference) of that Server
*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_65020875==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 10:44:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20986 for ; Wed, 17 Apr 2002 10:44:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14439; Wed, 17 Apr 2002 10:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14403 for ; Wed, 17 Apr 2002 10:41:56 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20877 for ; Wed, 17 Apr 2002 10:41:51 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA07336; Wed, 17 Apr 2002 07:41:09 -0700 (PDT) Message-Id: <4.1.20020417092140.01725b00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Apr 2002 09:41:07 -0500 To: Alistair Munro , Dean Bogdanovic , ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] a little homily - benefits of multicast In-Reply-To: <3CAD738A.C7B69DF5@degree2.com> References: <200204041804.g34I4qx01166@volta.mazunetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_66197767==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_66197767==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:51 AM 4/5/2002 +0100, Alistair Munro wrote: >Hi Dean, > >You are right, I am talking c**p and have got my G's mixed up. Sorry if >there was >any confusion. >8Kbps one which generates around 16 Kbps of RTP frames per direction (as >measured >by my LAN analyser and by the element itself). It is a G.7xx, but obviously >I do >not mean the 64 Kbps one. The "64 Kbps one" is not any G.7XX as measured by packet analyzers. 64kbps circuit mode (or source BW) throughput is actually ~ 80kbps packet mode (50 samples/sec) at L3 and could be from 85kbps (Ethernet framing) to 106kbps (when incorporating over ATM) on the wire with the additional headers and is the G.711 codec If you are measuring 16kbps in a single direction with your analyzer - then the audio has been compressed 4:1 from inbound BW (of 64kbps) - and it's likely the G.728 codec being used - which is employed primarily as the audio along with H.261/263 Video -- it's rarely used for strictly voice. just an fyi here... ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_66197767==_.ALT Content-Type: text/html; charset="us-ascii"
At 10:51 AM 4/5/2002 +0100, Alistair Munro wrote:
>Hi Dean,
>
>You are right, I am talking c**p and have got my G's mixed up. Sorry if
>there was
>any confusion.

>8Kbps one which generates around 16 Kbps of RTP frames per direction (as
>measured
>by my LAN analyser and by the element itself). It is a G.7xx, but obviously
>I do
>not mean the 64 Kbps one.

The "64 Kbps one" is not any G.7XX as measured by packet analyzers. 64kbps circuit mode (or source BW) throughput is actually ~ 80kbps packet mode (50 samples/sec) at L3 and could be from 85kbps (Ethernet framing) to 106kbps (when incorporating over ATM) on the wire with the additional headers and is the G.711 codec

If you are measuring 16kbps in a single direction with your analyzer - then the audio has been compressed 4:1 from inbound BW (of 64kbps) - and it's likely the G.728 codec being used - which is employed primarily as the audio along with H.261/263 Video -- it's rarely used for strictly voice.

just an fyi here... 


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_66197767==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 11:11:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22411 for ; Wed, 17 Apr 2002 11:11:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20629; Wed, 17 Apr 2002 11:10:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20573 for ; Wed, 17 Apr 2002 11:10:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22307 for ; Wed, 17 Apr 2002 11:10:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06861; Wed, 17 Apr 2002 11:09:38 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08787; Wed, 17 Apr 2002 11:09:34 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Apr 2002 11:09:25 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57CE68@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'James M. Polk'" , "'Alistair Munro'" , Ken Carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] a little homily - benefits of multicast Date: Wed, 17 Apr 2002 11:09:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E621.E0D18020" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E621.E0D18020 Content-Type: text/plain; charset="ISO-8859-1" Are we talking about the same thing? A transcoder would be a box on the net that took a stream with one codec in and put a stream with another codec out. So, perhaps you would have a box that would do G.729 to G.711 transcoding so that a phone that did not have a G.729 codec could talk to a phone that did, but refused to allow a G.711 call. In SIP terms, this would be a B2BUA in most cases. It would not include transcode functions that were part of a bridge, so that each participant could choose which codec it presented to the bridge. It wouldn't include transcodes that are part of a gateway (so you could take a G.729 call from a SIP phone and transcode it to a GSM codec for example). I'm differentiating these cases because at present we don't have standardized ways of locating transcoders or engaging them in SIP calls. For example, would it be the UA that decides it can't agree on a common codec with the other UA and engage the transcoder, or does a proxy server do that? How do you format the SIP message to the transcoder (if it is a B2BUA) so that it does the right thing? 'Standards' in this case is more appropriately "best practice' but since it involves at least 2 and possibly three elements, we need some agreement on how it's used. AFAIK transcoders as stand alone boxes are still uncommon, but they are functions that media servers are bringing out, so I would expect them to be more common in the future. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, April 17, 2002 10:22 AM To: Rosen, Brian; 'Alistair Munro'; Ken Carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] a little homily - benefits of multicast At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote: >Transcoders are at present uncommon, huh? We build several products that do this function by design -- and have for more than 2 (3?) years >and we might want to >get some work done in SIP to make it a little more standardized >how transcoders might be discovered and engaged. I would agree with this statement, but this is more a function of a Server in the route maybe causing a redirect to a known transcoder (like a conference) of that Server ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1E621.E0D18020 Content-Type: text/html; charset="ISO-8859-1"
Are we talking about  the same thing?
 
A transcoder would be a box on the net that took a stream with one codec in and put a stream
with another codec out.   So, perhaps you would have a box that would do G.729 to G.711
transcoding so that a phone that did not have a G.729 codec could talk to a phone that
did, but refused to allow a G.711 call.  In SIP terms, this would be a B2BUA in most cases.
 
It would not include transcode functions that were part of a bridge, so that each participant
could choose which codec it presented to the bridge.  It wouldn't include transcodes that
are part of  a gateway (so you could take a G.729 call from a SIP phone and transcode
it to a GSM codec for example).  I'm differentiating these cases because at present we
don't have standardized ways of locating transcoders or engaging them in SIP calls.
For example, would it be the UA that decides it can't agree on a common codec
with the other UA and engage the transcoder, or does a proxy server do that?
How do you format the SIP message to the transcoder (if it is a B2BUA) so that it
does the right thing?   'Standards' in this case is more appropriately "best practice'
but since it involves at least 2 and possibly three elements, we need some agreement
on how it's used.
 
AFAIK transcoders as stand alone boxes are still uncommon, but they are functions that media
servers are bringing out, so I would expect them to be more common in the future.
 
Brian
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Wednesday, April 17, 2002 10:22 AM
To: Rosen, Brian; 'Alistair Munro'; Ken Carlberg
Cc: ieprep@ietf.org
Subject: RE: [Ieprep] a little homily - benefits of multicast

At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote:

>Transcoders are at present uncommon,

huh? We build several products that do this function by design -- and have for more than 2 (3?) years

>and we might want to
>get some work done in SIP to make it a little more standardized
>how transcoders might be discovered and engaged.

I would agree with this statement, but this is more a function of a Server in the route maybe causing a redirect to a known transcoder (like a conference) of that Server
*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
------_=_NextPart_001_01C1E621.E0D18020-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 12:21:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25337 for ; Wed, 17 Apr 2002 12:21:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26303; Wed, 17 Apr 2002 12:19:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26271 for ; Wed, 17 Apr 2002 12:19:02 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25220 for ; Wed, 17 Apr 2002 12:18:57 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA25798; Wed, 17 Apr 2002 09:18:15 -0700 (PDT) Message-Id: <4.1.20020417110927.039d6f18@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Apr 2002 11:18:12 -0500 To: "Rosen, Brian" , "'Alistair Munro'" , Ken Carlberg From: "James M. Polk" Subject: RE: [Ieprep] a little homily - benefits of multicast Cc: ieprep@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF57CE68@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_72023083==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_72023083==_.ALT Content-Type: text/plain; charset="us-ascii" At 11:09 AM 4/17/2002 -0400, Rosen, Brian wrote: > > Are we talking about the same thing? yep > > > A transcoder would be a box on the net that took a stream with one codec in > and put a stream > with another codec out. that's the definition I know > > So, perhaps you would have a box several actually > > that would do G.729 to G.711 > transcoding so that a phone that did not have a G.729 codec could talk to a > phone that > did, for many many (blue) moons > > but refused to allow a G.711 call. this last part-sentence i don't follow, why would you refuse the G.711 call in the above scenario? And we current can't go G.7XX to GSM. It's a combination of G.711, G.723 and G.729 only for now > > In SIP terms, this would be a B2BUA in most cases. Again -- I agree we need to work on how to find the Transcoder within the session set-up, and then what it can and cannot do (signal and insert headers types of things). ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_72023083==_.ALT Content-Type: text/html; charset="us-ascii" At 11:09 AM 4/17/2002 -0400, Rosen, Brian wrote:
Are we talking about  the same thing?

yep

 
A transcoder would be a box on the net that took a stream with one codec in and put a stream
with another codec out.  

that's the definition I know

So, perhaps you would have a box

several actually

that would do G.729 to G.711
transcoding so that a phone that did not have a G.729 codec could talk to a phone that
did,

for many many (blue) moons

but refused to allow a G.711 call. 

this last part-sentence i don't follow, why would you refuse the G.711 call in the above scenario?

And we current can't go G.7XX to GSM. It's a combination of G.711, G.723 and G.729 only for now

In SIP terms, this would be a B2BUA in most cases.


Again -- I agree we need to work on how to find the Transcoder within the session set-up, and then what it can and cannot do (signal and insert headers types of things).

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_72023083==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 17:41:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08744 for ; Wed, 17 Apr 2002 17:41:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20629; Wed, 17 Apr 2002 17:40:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20598 for ; Wed, 17 Apr 2002 17:40:23 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08705 for ; Wed, 17 Apr 2002 17:40:18 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA25045 for ; Wed, 17 Apr 2002 14:39:51 -0700 (PDT) Message-Id: <4.1.20020417163349.014d7db8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Apr 2002 16:39:49 -0500 To: ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_91319480==_.ALT" Subject: [Ieprep] VoiceStream granted HPCC with 5 levels of Priority Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --=====================_91319480==_.ALT Content-Type: text/plain; charset="us-ascii" http://news.com.com/2100-1033-884902.html ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_91319480==_.ALT Content-Type: text/html; charset="us-ascii"



*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_91319480==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 17 23:24:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16339 for ; Wed, 17 Apr 2002 23:24:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08001; Wed, 17 Apr 2002 23:18:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07965 for ; Wed, 17 Apr 2002 23:18:34 -0400 (EDT) Received: from volta (209-6-26-7.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com [209.6.26.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16255 for ; Wed, 17 Apr 2002 23:18:26 -0400 (EDT) Received: from volta (dean@localhost) by volta (8.11.6/8.11.2) with ESMTP id g3I3HwS02251; Wed, 17 Apr 2002 23:17:58 -0400 Message-Id: <200204180317.g3I3HwS02251@volta> To: "Rosen, Brian" cc: "'James M. Polk'" , "'Alistair Munro'" , Ken Carlberg , ieprep@ietf.org Subject: Re: [Ieprep] a little homily - benefits of multicast In-Reply-To: Message from "Rosen, Brian" of "Wed, 17 Apr 2002 11:09:32 EDT." <313680C9A886D511A06000204840E1CF57CE68@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 17 Apr 2002 23:17:58 -0400 From: Dean Bogdanovic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org >For example, would it be the UA that decides it can't agree on a common >codec >with the other UA and engage the transcoder, or does a proxy server do that? >How do you format the SIP message to the transcoder (if it is a B2BUA) so >that it >does the right thing? Well we always have to persume that UAs have to be able to agree on common codec, because parts of the infratstructure can be nonoperational in emergency situation, so transcoder and proxy might not be available or the network distance might be unacceptable from quality perspective. And as I understood one of the goals of this WG is to come up with BCP, so we can propose cases what steps to take in order to prevent such failures which could stop communications. I know that the protocol groups have to know how to format headers, but they have to start from worst case scenario and minimum operational network. The beauty of SIP is that is decentralized and UA can comunicate directly without third nodes beeing involved. Lets try to pursue that model for ECS as much as possible. --br Dean > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Wednesday, April 17, 2002 10:22 AM >To: Rosen, Brian; 'Alistair Munro'; Ken Carlberg >Cc: ieprep@ietf.org >Subject: RE: [Ieprep] a little homily - benefits of multicast > > >At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote: > >>Transcoders are at present uncommon, > >huh? We build several products that do this function by design -- and have >for more than 2 (3?) years > >>and we might want to >>get some work done in SIP to make it a little more standardized >>how transcoders might be discovered and engaged. > >I would agree with this statement, but this is more a function of a Server >in the route maybe causing a redirect to a known transcoder (like a >conference) of that Server > >************************************* >"People generally demand more respect for their own rights than they are >willing to allow for others" > > >James M. Polk >Consulting Engineer >Office of the CTO > >Cisco Systems >2200 East President George Bush Turnpike >Richardson, TX 75082 USA >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > > >------_=_NextPart_001_01C1E621.E0D18020 >Content-Type: text/html; > charset="ISO-8859-1" > > > > > > > > >
Are we >talking about  the same thing?
>
color=#0000ff> 
>
A transcode r >would be a box on the net that took a stream with one codec in and put a >stream
>
with anothe r >codec out.   So, perhaps you would have a box that would do G.729 to >G.711
>
transcoding >so that a phone that did not have a G.729 codec could talk to a phone >that
>
did, but >refused to allow a G.711 call.  In SIP terms, this would be a B2BUA in mo st >cases.
>
color=#0000ff> 
>
It would no t >include transcode functions that were part of a bridge, so that each >participant
>
could choos e >which codec it presented to the bridge.  It wouldn't include transcodes >that
>
are part >of  a gateway (so you could take a G.729 call from a SIP phone and >transcode
>
it to a GSM >codec for example).  I'm differentiating these cases because at present >we
>
don't have >standardized ways of locating transcoders or engaging them in SIP >calls.
>
For example , >would it be the UA that decides it can't agree on a common >codec
>
with the >other UA and engage the transcoder, or does a proxy server do >that?
>
How do you >format the SIP message to the transcoder (if it is a B2BUA) so that >it
>
does the >right thing?   'Standards' in this case is more appropriately "best >practice'
>
but since i t >involves at least 2 and possibly three elements, we need some >agreement
>
on how it's >used.
>
color=#0000ff> 
>
AFAIK >transcoders as stand alone boxes are still uncommon, but they are functions th at >media
>
servers are >bringing out, so I would expect them to be more common in the >future.
>
color=#0000ff> 
>
color=#0000ff>Brian
>
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid"> >
size=2>-----Original Message-----
From: James M. Polk > [mailto:jmpolk@cisco.com]
Sent: Wednesday, April 17, 2002 10:22 > AM
To: Rosen, Brian; 'Alistair Munro'; Ken Carlberg
Cc: > ieprep@ietf.org
Subject: RE: [Ieprep] a little homily - benefits o f > multicast

>
At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote:

>
>Transcoders are at present uncommon,

>
huh? We build several products that do this function by design -- and > have for more than 2 (3?) years

>
>and we might want to
>
>get some work done in SIP to make it a little more standardized >
>how transcoders might be discovered and engaged.

I would > agree with this statement, but this is more a function of a Server in the > route maybe causing a redirect to a known transcoder (like a conference) of > that Server
>
*************************************
"People generally > demand more respect for their own rights than they are willing to allow for > others"

James M. Polk
Consulting Engineer
Office of the > CTO

Cisco Systems
2200 East President George Bush Turnpike >
Richardson, TX  75082 USA
w) 972.813.5208
f)  > 972.813.5280
eudora="autourl">www.cisco.com
> >------_=_NextPart_001_01C1E621.E0D18020-- > >_______________________________________________ >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 From ieprep-admin@ietf.org Thu Apr 18 10:14:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07089 for ; Thu, 18 Apr 2002 10:14:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29017; Thu, 18 Apr 2002 10:13:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28971 for ; Thu, 18 Apr 2002 10:13:53 -0400 (EDT) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07056 for ; Thu, 18 Apr 2002 10:13:48 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id HAA29828 for ; Thu, 18 Apr 2002 07:11:41 -0700 (MST) Received: from mknaomi ([130.131.166.58]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with SMTP id AAA4E14 for ; Thu, 18 Apr 2002 07:13:37 -0700 Received: FROM agcs.com BY mknaomi ; Thu Apr 18 07:13:36 2002 -0700 Message-ID: <3CBED498.75C58C53@agcs.com> Date: Thu, 18 Apr 2002 07:13:44 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: ieprep@ietf.org Subject: Re: [Ieprep] clarifications about security X-Priority: 4 (Low) References: <5.1.0.14.2.20020405103410.02300df0@mira-sjcm-4.cisco.com> Content-Type: multipart/mixed; boundary="------------AE0D6B1EC395A56854BB3276" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. --------------AE0D6B1EC395A56854BB3276 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fred, I loved your "medical example" and I fully agree that the best defense for an unexpected attack is to have many defense mechanisms available. Fred Baker wrote: snip Also, firewalls do not provide security; they reduce risk. Let me give you > a medical example: your body. Your body has a firewall, in the form of an > organ called the "skin". It serves as a fairly effective barrier against > all sorts of junk getting into your body, and reduces the risks that the > rest of the immune system needs to deal with. However, anyone who thinks > the skin is sufficient as a defence hasn't thought through AIDS or even the > common cold. The body backs up the skin with a fairly intricate and > effective intrusion detection and management system that deals with attacks > on the cell level (lymphocytes), the wound level (platelets, the lymph > system, and so on), and at the infection level (for example shutting down > perspiration and raising the body temperature to kill a widespread infection). > > In the end, security is always a matter of risk reduction, and as far as I > know there is no single technology that obviates the risk of internal > attack as well as external attack, or addresses all attacks. > > What seems to be the requirement to bring out in this case is that the > networks impose appropriate defences, which may include firewalls and > proxies, and may well include intrusion detection systems and other mechanisms. --------------AE0D6B1EC395A56854BB3276 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org: adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;23888 fn:Stuart Goldman end:vcard --------------AE0D6B1EC395A56854BB3276-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Apr 18 10:52:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08980 for ; Thu, 18 Apr 2002 10:52:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02149; Thu, 18 Apr 2002 10:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02113 for ; Thu, 18 Apr 2002 10:51:43 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08932 for ; Thu, 18 Apr 2002 10:51:34 -0400 (EDT) Received: from degree2.com (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g3IEpX723302; Thu, 18 Apr 2002 15:51:33 +0100 Message-ID: <3CBEDE82.9010103@degree2.com> Date: Thu, 18 Apr 2002 15:56:02 +0100 From: Alistair Munro User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Bogdanovic CC: ieprep@ietf.org Subject: [Ieprep] transcoding and decentralisation References: <200204180317.g3I3HwS02251@volta> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, Sorry, I had to remove the "a little homily on multicast" from the subject as we have strayed a long way from that thread. >Well we always have to persume that UAs have to be able to agree on >common codec, because parts of the infratstructure can be >nonoperational in emergency situation, so transcoder and proxy might >not be available or the network distance might be unacceptable from >quality perspective. And as I understood one of the goals of this WG is >to come up with BCP, so we can propose cases what steps to take in >order to prevent such failures which could stop communications. >I know that the protocol groups have to know how to format headers, >but they have to start from worst case scenario and minimum >operational network. The beauty of SIP is that is decentralized and UA >can comunicate directly without third nodes beeing involved. Lets try >to pursue that model for ECS as much as possible. > Decentralisation is essential to survive an emergency situation or attack - I think that this is a general principle. The Internet does it a network level - that's what it's for after all, and it's under attack all the time, mostly from itself by many accounts (extension of the immunity analogy Fred suggested for security?). Applications must similarly be decentralised - which is less obvious but I'm sure we can write down what is done currently. For example for voice, where SIP will fit the requirement, emergency services use direct mode (their term) voice in an open channel (similar to rat/vat operating over multicast). This function comes for free with typical IP phones. The transcoding issue seems orthogonal to the survivability issue. If it is necessary to use a proxy/server to do any forwarding/switching/interworking function then the application (by which I mean the aggregate of all the participating physical objects and their interconnect) should be configurable to adapt to failure of any single point, possibly more than a single point. As to preventing failure - attaining a desired bound on the likelihood of failure is planning, design and $ choice, not a requirement. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.degree2.com, http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 23 07:15:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12149 for ; Tue, 23 Apr 2002 07:15:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18912; Tue, 23 Apr 2002 07:14:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18872 for ; Tue, 23 Apr 2002 07:14:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11989; Tue, 23 Apr 2002 07:14:28 -0400 (EDT) Message-Id: <200204231114.HAA11989@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Apr 2002 07:14:27 -0400 Subject: [Ieprep] I-D ACTION:draft-schulzrinne-ieprep-resource-req-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Resource Priority Mechanisms for the Session Initiation Protocol Author(s) : H. Schulzrinne Filename : draft-schulzrinne-ieprep-resource-req-00.txt Pages : 4 Date : 22-Apr-02 This document summarizes requirements for prioritizing access to PSTN and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ieprep-resource-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ieprep-resource-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ieprep-resource-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-ieprep-resource-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-ieprep-resource-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135356.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Apr 24 17:36:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09984 for ; Wed, 24 Apr 2002 17:36:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03093; Wed, 24 Apr 2002 17:35:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03031 for ; Wed, 24 Apr 2002 17:35:33 -0400 (EDT) Received: from chntex01.is.dyncorp.com (chntex01.is.dyncorp.com [131.131.133.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09978 for ; Wed, 24 Apr 2002 17:35:28 -0400 (EDT) Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <2P239JAZ>; Wed, 24 Apr 2002 17:34:37 -0400 Message-ID: From: "Gunn, Janet NE" To: "'ieprep@ietf.org'" Date: Wed, 24 Apr 2002 17:34:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EBD7.D4F16390" Subject: [Ieprep] IEPREP Interim Meeting? Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EBD7.D4F16390 Content-Type: text/plain; charset="iso-8859-1" The minutes from the IEPREP WG meting say that an interim meeting will be held in May or June. Have there been any developments on date or locations? ------_=_NextPart_001_01C1EBD7.D4F16390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IEPREP Interim Meeting?

The minutes from the IEPREP WG meting = say that an interim meeting will be held in May or June.  Have = there been any developments on date or locations?

------_=_NextPart_001_01C1EBD7.D4F16390-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Apr 26 15:44:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01642 for ; Fri, 26 Apr 2002 15:44:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19328; Fri, 26 Apr 2002 15:42:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19294 for ; Fri, 26 Apr 2002 15:42:54 -0400 (EDT) Received: from imo-r08.mx.aol.com (imo-r08.mx.aol.com [152.163.225.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01335 for ; Fri, 26 Apr 2002 15:42:50 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v32.5.) id l.27.26867c56 (25512) for ; Fri, 26 Apr 2002 15:42:17 -0400 (EDT) Message-ID: <27.26867c56.29fb0798@aol.com> Date: Fri, 26 Apr 2002 15:42:16 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_27.26867c56.29fb0798_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] "Assured Service" drafts Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_27.26867c56.29fb0798_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have uploaded the following three drafts. Although directed to SIPPING, the principles addressed may also apply to IEPREP as noted. draft-pierce-sipping-assured-service-02 is a further revision of the previous draft to define the requirements. Informative material has been moved to the following two drafts. (For IEPREP, most of the requirements described here should apply.) draft-pierce-sipping-assured-service-arch-00 defines the architecture which is assumed to be necessary to meet the requirements for Assured Service. It describes the use of a trusted proxy to handle origination and termination of Assured Service calls. (The architecture described is also needed for IEPREP to address the issues of security.) draft-pierce-sipping-pref-treat-examples-00 describes ways in which preferential treatment can be provided to high priority calls. It focuses on meeting the requirements for "Assured Service" as defined in the above requirements, but the procedures described may also be used in other cases such as the "Emergency Preparedness" services. Mike Pierce Artel --part1_27.26867c56.29fb0798_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have uploaded the following three drafts. Although directed to SIPPING, the principles addressed may also apply to IEPREP as noted.

draft-pierce-sipping-assured-service-02 is a further revision of the previous draft to define the requirements. Informative material has been moved to the following two drafts. (For IEPREP, most of the requirements described here should apply.)

draft-pierce-sipping-assured-service-arch-00 defines the architecture which is assumed to be necessary to meet the requirements for Assured Service. It describes the use of a trusted proxy to handle origination and termination of Assured Service calls. (The architecture described is also needed for IEPREP to address the issues of security.)

draft-pierce-sipping-pref-treat-examples-00 describes ways in which preferential treatment can be provided to high priority calls. It focuses on meeting the requirements for "Assured Service" as defined in the above requirements, but the procedures described may also be used in other cases such as the "Emergency Preparedness" services.

Mike Pierce
Artel




--part1_27.26867c56.29fb0798_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Apr 27 01:47:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10189 for ; Sat, 27 Apr 2002 01:47:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23538; Sat, 27 Apr 2002 01:47:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23506 for ; Sat, 27 Apr 2002 01:47:29 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10124 for ; Sat, 27 Apr 2002 01:47:25 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3R5kdph005573 for ; Fri, 26 Apr 2002 22:46:52 -0700 (PDT) Message-Id: <5.1.0.14.2.20020426192810.01c0a808@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 20:15:49 -0400 To: ieprep@ietf.org From: Fred Baker Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. In-Reply-To: <3CB53346.1080905@degree2.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:55 AM 4/11/2002 +0100, Alistair Munro wrote: >functional/service requirements from the ETS side (your draft), and >solutions from the IP side (Fred's draft). I like very much your A. - K >paragraphs in section 4 as a list of requirements for the ETS I agree that functional requirements are needed. If I can say this without appearing to slam Hal's draft (which I consider a very reasonable start on something which might be entitled "US Government requirements of an ETS"), I personally find it to be a list of glittering generalities, some of which are mutually contradictory. I'm not at all sure how to design a service that meets those requirements. Let's take "the network must be secure" as an example (and of course ignoring Ian's recent comments on the list). It is not clear to me whether the draft requires - Physical isolation of the network from the Internet backbone (which is seen as insecure), or - Use of Code Division Multiple Access signaling to reduce the probability of jamming interference with a radio signal, or - Use of Ultra-Wideband signaling to provide limited probability of detection of a radio signal, or - Use of technologies to prevent and detect interference or interdiction of a signal (such as placing fiber in a pressurized ABS pipe to detect attempts to bend the fiber to capture leaking lambdas), or - Use of type 1 encryption on all communications links, or fragentation and reordering of traffic in a transaction with fill traffic taking up any excess bandwidth on the line to prevent or limit traffic analysis - Strong authentication and perhaps encryption of every transaction (email, web, file transfer, database access, whatever) end to end using a mechanism such as IPSEC (is the blackberry to blackberry or IMM server to IMM server, or both?), or - Continuity and privacy of communication needs to be provided at the transport layer in a manner which traverses firewalls and NATs, such as TLS, or - Communication is required to be proof positive against denial of service attacks, viruses, or worms, or - Fast detection and operator interdiction of network overloads resulting from such attacks, or - Intrusion Detection Services (such as provided by a variety of products including my company's Net Ranger product) need to be deployed to automatically detect and interdict attacks, - Firewalls (such as CheckPoint or PIX) need to be deployed for perimeter protection, or - Tracing of hackers and ddos attacks to their sources, whether zombie system or the actual script kiddie, or - requiring ISPs to have their users "log in" in some manner (which seems to me superfluous; they have their own requirements in this area, dictated by their business), or - Routing needs to neighbor authentication to reduce risk of misrouting on incorrect data, or - Each route needs to be digitally signed to preclude transitive routing faults that neighbor authentication would not prevent, or - Digital signatures on XML records to ensure their authenticity in the database they were read from (eg, demonstrate to me that the record presented to me as a library of congress record is in fact from that place and is in fact exactly the authoritative record that someone wrote there 32 years ago) - Digital signatures on DNS records to ensure authenticated name-to- address translation (DNSSEC), or - Logging of all transactions (does that apply to DNS lookups? Transmission of log records?), or - Reasonable and customary protections (including any or all of the above as appropriate in the environment du jour) need to be provided against malicious or misconfigured behavior. I can think of communication environments where each of those bullets is a reasonable interpretation, and where it is in fact the operative interpretation or part of it. My last bullet is (I hope Hal doesn't mind me trying to put words into his mouth) probably what is actually intended. Without explanation of the requirement, I can't tell whether we have succeeded in meeting it, and I'm pretty certain we won't meet every possible variation on it (exactly how do you ensure that nobody can attack you, ever?). Any of those interpretations of "secure" can be inconsistent with the service being anonymous, which is also one of the bulleted requirements. Once I put an encrypting key or authenticating hash on something, I at minimum know that the composer or sender of a message is one of the persons or devices that knows the key or hash to use. I often know that only one person should know that key or hash, whether his or her name is included or not. So I think what needs to happen to that draft, if we are to make it a working group output, is that it must either be generalized beyond US Government requirements or it must be re-entitled "US Government Requirements..." It also must be extended to the next level of detail on each of the points, giving an analysis of what is being requested in each bullet, why, and in what environments that consideration is applicable. As I understand the charter, the requirements document is not to be a BCP, and there is no need for there to be one requirements document. Requirements documents are generally informational. In fact, I think it might be simplest for us to present a number of requirements documents that describe US Government requirements, requirements for the SIP service, requirements for data services, and so on. The BCP or BCPs would be the recommended procedures that respond to the drafts. If the requirement, for example, is that a network be secure in some sense, a BCP for network security might address the types of authentication that are recommended for use in this type of service, when encryption is necessary and what types are appropriate or inappropriate, and so on. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Apr 27 01:47:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10206 for ; Sat, 27 Apr 2002 01:47:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23500; Sat, 27 Apr 2002 01:47:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23466 for ; Sat, 27 Apr 2002 01:47:23 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10108 for ; Sat, 27 Apr 2002 01:47:19 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3R5kdpf005573 for ; Fri, 26 Apr 2002 22:46:44 -0700 (PDT) Message-Id: <5.1.0.14.2.20020426191751.01b0e590@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 19:23:13 -0400 To: "'ieprep@ietf.org'" From: Fred Baker Subject: Re: [Ieprep] IEPREP Interim Meeting? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 05:34 PM 4/24/2002 -0400, Gunn, Janet NE wrote: >The minutes from the IEPREP WG meting say that an interim meeting will be >held in May or June. Have there been any developments on date or locations? DISA (Don Choi) has offered to host a meeting in Washington DC on May 20, from 9:00 to 2:00. I'm technically a little late announcing that - I should have done so by April 20, for various reasons including travel issues. My lame excuse is that I visited DISA on Wednesday, and I wanted to actually announce the meeting subsequent to said visit. My reason for calling an interim is partly that I think we probably have enough on the table to have a useful discussion, and can lay out a road map in that meeting towards a consensus call on final documents agreed to in Yokohama. I would like, specifically, to discuss: - A presentation from DISA (proposed by Don Choi) clarifying DISA issues and requirements - Henning Schulzrin's SIP MLPP and e911 requirements - James Polk's SIP response to that draft - Cory Beard's document - an update to Hal's requirements document - any changes that Ken has made to his framework proposal, and the future of that proposal - direction for the BCP(s), including a table of contents and solicitation of text for it And I would like to further discuss things that have been of interest in on the mailing list. We probably also have other things to discuss; folks who want to have a particular discussion should send me a note privately or post to the list. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 29 18:30:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21699 for ; Mon, 29 Apr 2002 18:30:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26244; Mon, 29 Apr 2002 18:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26210 for ; Mon, 29 Apr 2002 18:28:48 -0400 (EDT) Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21634 for ; Mon, 29 Apr 2002 18:28:44 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4453); Mon, 29 Apr 2002 17:28:43 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EFCD.3847F586" Date: Mon, 29 Apr 2002 17:28:43 -0500 Message-ID: Thread-Topic: AF for Elastic Traffic Thread-Index: AcHvzTLxhvoXr1uVEdaHNgBQBJSk2g== From: "Beard, Cory" To: X-OriginalArrivalTime: 29 Apr 2002 22:28:43.0977 (UTC) FILETIME=[3895F390:01C1EFCD] Subject: [Ieprep] AF for Elastic Traffic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1EFCD.3847F586 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In Section 2.4.3 in Fred's draft, he talks about requirements for = supporting elastic traffic. He says, "Routers used in supporting = bottleneck points in an IEPS service should therefore also support = Assured Forwarding." =20 What other ways could a service provider provide an acceptable ieprep = solution for web browsing (or other types of elastic applications that = involve user interaction) without using AF? Overprovisioning is one, as = long as they can show that the overprovisioning will persist even in = high traffic conditions after a disaster. Anything else? None readily = come to mind for me. =20 Do we have a clear dividing line when it comes to supporting interactive = elastic traffic? Either a provider heavily overprovisions and does not = turn on diff-serv, or they use AF? =20 Cory Beard =20 ------_=_NextPart_001_01C1EFCD.3847F586 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In = Section 2.4.3 in=20 Fred's draft, he talks about requirements for supporting elastic = traffic. =20 He says,=20 "Routers used in supporting bottleneck points in an IEPS service should=20 therefore also support Assured Forwarding."
 
What = other ways=20 could a service provider provide an acceptable ieprep solution for = web=20 browsing (or other types of elastic applications that involve user = interaction)=20 without using AF?  Overprovisioning is one, as long as they can = show that=20 the overprovisioning will persist even in high traffic conditions after = a=20 disaster.  Anything else? None readily come to mind for=20 me.
 
Do we = have a clear=20 dividing line when it comes to supporting interactive elastic = traffic? =20 Either a provider heavily overprovisions and does not turn on diff-serv, = or they=20 use AF?
 
Cory = Beard
 
------_=_NextPart_001_01C1EFCD.3847F586-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 29 19:35:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23214 for ; Mon, 29 Apr 2002 19:35:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02280; Mon, 29 Apr 2002 19:33:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02250 for ; Mon, 29 Apr 2002 19:33:15 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23155 for ; Mon, 29 Apr 2002 19:33:12 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3TNWfpZ029409; Mon, 29 Apr 2002 16:32:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20020429161501.0263fe00@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 16:32:41 -0700 To: "Beard, Cory" From: Fred Baker Subject: Re: [Ieprep] AF for Elastic Traffic Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 05:28 PM 4/29/2002 -0500, Beard, Cory wrote: >What other ways could a service provider provide an acceptable ieprep >solution for web browsing (or other types of elastic applications that >involve user interaction) without using AF? Overprovisioning is one, as >long as they can show that the overprovisioning will persist even in high >traffic conditions after a disaster. Anything else? None readily come to >mind for me. > >Do we have a clear dividing line when it comes to supporting interactive >elastic traffic? Either a provider heavily overprovisions and does not >turn on diff-serv, or they use AF? The fundamental assertion being made in this context is that it is possible for there to be so much traffic that any level of overprovisioning can be overwhelmed, and at that point one has to decide what one will do. That is, I think, a true statement; the question is what is feasible, or is a realistic response to a credible threat. Personally, I think service provider overprovisioning is more than adequate in the cores of their networks. Some service providers say, for example, that they have deployed a network would is ~2% utilized; many and perhaps most say that their interfaces average something on the order of 10% utilization. They all tell us that in recent examples of "Internet under crisis", this level of overprovisioning has been more than adequate. So I don't expect the service providers to increase their level of overprovisioning based on the outputs of this working group. Where I routinely have service providers asking me questions relates to their handling of traffic they don't feel obligated to. For example, last week I visited a (nameless) ISP that says that it finds a lot of Morpheus servers among its clients; a couple of years ago, another ISP spoke with me about people originating real-time video. Now, such ISPs SLAs to their customers is that they can only originate some specific rate, and (unless they pay for such a service) they are not supposed to run servers. A PC running a Morpheus server is acting as a server, and BTW the home is unaware of that service. So they find themselves running various technologies, including classifiers that will identify and eliminate Morpheus traffic from their networks. But this requires them to be agile - if Morpheus won't work, will Gnutella?. So I advise them to meter the traffic originated by a customer, and mark it AFx1 or AFx2 depending on whether it is too fast or not, and when it gets to a point that costs the ISP money, drop the "excess" traffic. The interesting issue here is that deciding to turn that on is non-trivial. You want it to be happening all the time, even if nothing is getting dropped, so that when the need arises it simply cuts in. I will argue that the same is true for emergency use. The places where you are most likely to see problems is at network access interfaces. There, you want to have traffic marked. If the traffic normally needs no help, fine; if it at some point suddenly needs support, the service is there, all you have to do is play with the numbers to make it work. By all means, overprovision, but do so in a manner that you can support from a business perspective. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Apr 29 20:00:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23837 for ; Mon, 29 Apr 2002 20:00:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03793; Mon, 29 Apr 2002 19:58:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03758 for ; Mon, 29 Apr 2002 19:58:25 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23805 for ; Mon, 29 Apr 2002 19:58:22 -0400 (EDT) Received: from 213.78.76.219 by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 30 Apr 2002 00:58:19 +0100 From: Ian Brown To: "Beard, Cory" , ieprep Subject: RE: [Ieprep] AF for Elastic Traffic Date: Tue, 30 Apr 2002 00:58:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit >What other ways could a service provider provide an acceptable ieprep >solution for web browsing (or other types of elastic applications that >involve user interaction) without using AF? I think that for web browsing, the most important service would be an Akamai-style highly distributed caching of sites that a customer (such as the US gov't) felt were important in an emergency. This would allow access for that customer's users and also potentially the public, reducing to some extent general congestion in the network. But this obviously doesn't help as much if there is high congestion in an emergency user's access network. And it would be nice if anycast could be widely deployed to help in the case of severe congestion in an important web site's provider network. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 30 05:39:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11556 for ; Tue, 30 Apr 2002 05:39:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09181; Tue, 30 Apr 2002 05:14:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09145 for ; Tue, 30 Apr 2002 05:14:47 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11241 for ; Tue, 30 Apr 2002 05:14:43 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Apr 2002 10:14:25 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Ian Brown cc: "Beard, Cory" , ieprep Subject: Re: [Ieprep] AF for Elastic Traffic In-reply-to: Your message of "Tue, 30 Apr 2002 00:58:37 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Apr 2002 10:14:24 +0100 Message-ID: <680.1020158064@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ian, I agree about the usefulness fo akamai-style distributed service and re-directs. however... > But this obviously doesn't help as much if there is high congestion in an > emergency user's access network. And it would be nice if anycast could be > widely deployed to help in the case of severe congestion in an important web > site's provider network. unless I've missed some recent developments, I have very small hopes for Anycast in the wide area. anycast amounts to the propagation of host routes -- which could be argued as ok for intra-site/domain use, but just won't fly (ie, horrible scaling) for inter-domain at the network level ala BGP. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 30 16:59:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08797 for ; Tue, 30 Apr 2002 16:59:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25018; Tue, 30 Apr 2002 16:59:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24984 for ; Tue, 30 Apr 2002 16:59:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08706 for ; Tue, 30 Apr 2002 16:59:00 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-171-71-107-16.cisco.com [171.71.107.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3UKwRpZ025538; Tue, 30 Apr 2002 13:58:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20020430131944.01ae5f48@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 13:58:28 -0700 To: Ken Carlberg From: Fred Baker Subject: Re: [Ieprep] AF for Elastic Traffic Cc: ieprep In-Reply-To: <680.1020158064@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:14 AM 4/30/2002 +0100, Ken Carlberg wrote: >I have very small hopes for Anycast in the wide area. anycast amounts to >the propagation of host >routes -- which could be argued as ok for intra-site/domain use, but just >won't fly (ie, horrible scaling) for inter-domain at the network level ala BGP. huh? you're perhaps unaware of it, but one of the DNS Roots has for a while run as an anycast service. Anycast works just fine. Certainly we need a host address for each service offered in that way, which means some form of insertion into IGP routing in an ISP network. That could be propagated to a neighboring network, but in the general case I don't see that it would be. Rather, the service would co-locate and contract with SPs that it deems important, and even if the SP tried to export the address, his neighbors would be unlikely to trust him for it. So an SP is absolutely in control of his routing - it is what he has accepted a contract to carry. I'm going to guess that some on the list are wondering what in the world anycast is, and how Akamai relates. If you already know or don't care, skip to the last couple of paragraphs. We have the capability in DNS to offer multiple translations of a name - DNS resolution of www.example.com might well get half a dozen addresses back, from which the end system is supposed to choose at random. What that means, of course, is that an end system might randomly choose the least advantageous one or the most advantageous one, and has no guidance in making that choice. Another way to do the same is to select a single address, put that address on each of half a dozen systems, translate the name to the address, and then have a router in front of those various systems that claims to be the right router to get to that address. Standard internet routing will get you from where you are to the nearest of those systems - you always specify the same thing, and you always make the most advantageous choice. There are other issues; if you start a long session and routing changes midstream, suddenly you're talking to a different server, and it has no idea what you're talking about. The best solution to that issue I have run across depends on "optimized routing" of "mobile IP". In Mobile IP, we use one address as a variety of name, send a message to where routing makes it appear to be, and have a system on route (called a home agent) intercept the message and tunnel it to the actual target. In the "optimized routing" variant of that, the target system replies from the address it is topologically located at (a temporary address appropriate to its temporary location) carrying the original address in its "Home Address Option". I claim that if we treat the anycast common address as a "home address", and have each instance of a server responding to the anycast address in fact reply from its topological address with the anycast address in the Home Address Option, we work around the robustness issues. Akamai accomplishes the same result, but in a different way. When you download a web page that has been "Akamaized", the URLs in it are replaced with special URLs (called ARLs) that point towards Akamai. The Akamai system compares the source address of the name lookup to a map and replies with one of 13,000 addresses of servers out in the great wide world. The net effect of each (no pun intended) is to minimize the round trip delay on a session by selecting the most accessible server, and to maximize available bandwidth by forcing different clients to access different servers. In so doing, Ian is proposing that this potentially moves traffic away from links carrying critical traffic, leaving capacity to be used by other traffic including the emergency traffic. I will agree that maximizing capacity as compared to offered load, by whatever means (buying big links is helpful too), will help in carrying that traffic. The question before the house is: can we expect that there will therefore be no issue for elastic traffic? I submit that we cannot definitively say. If offered load suddenly jumps by 1-2 orders of magnitude, as happened on the access links of some media sites on 9/11, it is very reasonable to believe that one could run into a problem; those media sites certainly did. Some of those media outlets, BTW, were Akamized on that date, and some of which were not; for the Akamized servers, ~.akamaitech.com was bottleneck as much as the other fellows servers were. The question becomes: in such a case, what decisions do we make, and how are they justified? However, our experience to date (Kobe, 9/11, and so on) suggests that backbone capacity is not seriously at risk. The issues are in the access, and the access tends to be specific to the set of servers behind it. The fact that CNN and New York Times were effectively inaccessible for a major part of 9/11 has no bearing on whether AOL was able to run AIM inside their network - there were few if any network paths that were used by both. The important thing is: can we ensure that traffic requiring a certain class of service in fact gets what it needs from the servers and access paths that are critical to them? From my perspective, - overprovisioning is a standard practice, but it is possible for crisis loads to exceed predicted demand in access paths - AF allows you to identify substreams within a traffic stream and "do the right thing" with them in the access path, and - there are serious firewall and server issues that have to be dealt with as well. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Apr 30 18:33:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11179 for ; Tue, 30 Apr 2002 18:33:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00941; Tue, 30 Apr 2002 18:33:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00907 for ; Tue, 30 Apr 2002 18:33:10 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11169 for ; Tue, 30 Apr 2002 18:33:05 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Apr 2002 23:31:10 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Fred Baker cc: ieprep Subject: Re: [Ieprep] AF for Elastic Traffic In-reply-to: Your message of "Tue, 30 Apr 2002 13:58:28 PDT." <5.1.0.14.2.20020430131944.01ae5f48@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Apr 2002 23:31:10 +0100 Message-ID: <27263.1020205870@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > huh? you're perhaps unaware of it, but one of the DNS Roots has for a while > run as an anycast service. Anycast works just fine. right, a single instance of a single well known server works. i won't argue with that. > Certainly we need a host address for each service offered in that way, > which means some form of insertion into IGP routing in an ISP network. That > could be propagated to a neighboring network, but in the general case I > don't see that it would be. Rather, the service would co-locate and > contract with SPs that it deems important, and even if the SP tried to > export the address, his neighbors would be unlikely to trust him for it. So > an SP is absolutely in control of his routing - it is what he has accepted > a contract to carry. ok, and this is a different model than i'm used to, though it does fall under the "ok for intra-site/domain use" as i mentioned earlier...ie, fine for IGP routing. but i can't see the Anycast address being propagated via BGP routing, which was the bone of contention in my original note. i'm still pessimistic about the scaling of Anycast in the event that it magically takes off and people/businesses try to use it to contract thousands of services to a select set of SP's deemed 'important'. just call me a Doubting Thomas on this subject. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep