From mailnull@www1.ietf.org Thu Jan 2 18:18:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16755 for ; Thu, 2 Jan 2003 18:18:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02NQwH31168 for ieprep-archive@odin.ietf.org; Thu, 2 Jan 2003 18:26:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NQwJ31165 for ; Thu, 2 Jan 2003 18:26:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16734 for ; Thu, 2 Jan 2003 18:17:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NPOJ31121; Thu, 2 Jan 2003 18:25:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NOBJ31061 for ; Thu, 2 Jan 2003 18:24:11 -0500 Received: from cam-po2.genuity.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16708 for ; Thu, 2 Jan 2003 18:15:11 -0500 (EST) Received: from pcain2000 (wob-dhcp175-240.genuity.com [171.78.175.240]) by cam-po2.genuity.com (8.11.3/8.11.2) with SMTP id h02NIIB18105; Thu, 2 Jan 2003 18:18:18 -0500 (EST) From: "pat cain" To: "James M. Polk" Cc: Subject: RE: [Ieprep] Revised Topologies ID for WG consideration Date: Thu, 2 Jan 2003 18:18:17 -0500 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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <4.1.20021024083035.02a8b4d0@localhost> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, I read the scenarios-02 document. I had a couple of comments and one odd suggestion. [I know this is not a WG document (yet). But I figured I'd be nice and share my comments.] Comments: 1. I like short IDs. Good job. Very crisp. I hope this one stays short. 2. The four scenarios sound right, but I had problems with section 2.4 "End-to-End-IP". The picture in 2.4 shows the IP Network as one big blob -- which I interpret (probably incorrectly) as one network provider. I think this is the easy scenario. I would suggest that the one blob be shown as two little blobs with an interconnection, as I expect most of the scenario busters are going to be in getting different parts of the "Inter"-net to "inter"-work. The last months of QoS and, now, NAT, on the mail list make me believe that getting a call across multiple IP networks may not be as easy as one big 'blob', and it really needs to be shown as multiple 'little blobs'. I don't worry about this as much for the CSN pictures, as getting CSNs to talk to each other has already been discovered (and maybe standardized), but I think it will be painful for the multiple provider call across the Internet. Particularly when one examines control traffic. The odd suggestion: 3. Would it be useful to add a wee bit of control flow, or ascii-art control boxes, to the pictures? This may complicate the pictures too much, but as I walked through the scenarios in my head, I started out with "the call starts here. And hits this controller. Which opens up an SS7 connection to here... which must be someplace over here. And that opens a UDP stream to... etc etc." I don't expect that we'll do any real detailed call flows in this or any other document, but we'll make requirements decisions based on some assumptions about those flows, it may be nice to have them. The reason this is an 'odd suggestion' is that I can't point out specific things to do to the pictures, but I think there is some control detail that's going to be necessary. Unless you think it's to much complication. Maybe just a "X" for where the call manager et al, if neccesary, goes. ? Nice document. Pat (I return you to the who's got more QoS in their NAT discussion) :) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 2 19:11:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17502 for ; Thu, 2 Jan 2003 19:11:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030KMA02248 for ieprep-archive@odin.ietf.org; Thu, 2 Jan 2003 19:20:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030KMJ02245 for ; Thu, 2 Jan 2003 19:20:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17498 for ; Thu, 2 Jan 2003 19:11:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030J3J02186; Thu, 2 Jan 2003 19:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030IaJ02166 for ; Thu, 2 Jan 2003 19:18:36 -0500 Received: from wells.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17482 for ; Thu, 2 Jan 2003 19:09:34 -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 QAA22348; Thu, 2 Jan 2003 16:12:43 -0800 (PST) Message-Id: <4.1.20030102180247.033e7240@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Jan 2003 18:12:36 -0600 To: "pat cain" From: "James M. Polk" Subject: RE: [Ieprep] Revised Topologies ID for WG consideration Cc: In-Reply-To: References: <4.1.20021024083035.02a8b4d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Pat comments in-line At 06:18 PM 1/2/2003 -0500, pat cain wrote: >James, > > >2. The four scenarios sound right, but I had problems with section 2.4 >"End-to-End-IP". >The picture in 2.4 shows the IP Network as one big blob -- which I interpret >(probably incorrectly) as one network provider. I think this is the easy >scenario. I would suggest that the one blob be shown as two little blobs >with an interconnection, as I expect most of the scenario busters are going >to be in getting different parts of the "Inter"-net to "inter"-work. The >last months of QoS and, now, NAT, on the mail list make me believe that >getting a call across multiple IP networks may not be as easy as one big >'blob', and it really needs to be shown as multiple 'little blobs'. An all IP (with no CSN) packet flow (with or without) separate control planes needed to be named within this WG - this document does this in its simplest form. While I agree generally that it will not likely be the case that an actual IEPREP call/session be placed only over a single IP provider, it is a slippery slope in establishing (or ASCII drawing) something that represents the e2e IP topology in multi-domain scenarios. The Internet is implied to be a series of loosely connected IP domains. Are you asking that this be explicitly stated in section 2.4 for clarity? > >The odd suggestion: >3. Would it be useful to add a wee bit of control flow This is the topic of another and purposely separate ID coming very soon > >Nice document. > >Pat >(I return you to the who's got more QoS in their NAT discussion) :) > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 3 14:51:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17687 for ; Fri, 3 Jan 2003 14:51:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03K0UM20626 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 15:00:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03K0UJ20623 for ; Fri, 3 Jan 2003 15:00:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17678 for ; Fri, 3 Jan 2003 14:51:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JwNJ20503; Fri, 3 Jan 2003 14:58:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JviJ20420 for ; Fri, 3 Jan 2003 14:57:44 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17584 for ; Fri, 3 Jan 2003 14:48:18 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id B4F6267103; Fri, 3 Jan 2003 14:55:32 -0500 (EST) Date: Fri, 3 Jan 2003 14:51:28 -0500 Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "pat cain" , To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20030102180247.033e7240@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Jan 2, 2003, at 19:12 America/Montreal, James M. Polk wrote: > At 06:18 PM 1/2/2003 -0500, pat cain wrote: >> 2. The four scenarios sound right, but I had problems with section 2.4 >> "End-to-End-IP". >> The picture in 2.4 shows the IP Network as one big blob -- which I >> interpret >> (probably incorrectly) as one network provider. I think this is the >> easy >> scenario. I would suggest that the one blob be shown as two little >> blobs >> with an interconnection, as I expect most of the scenario busters are >> going >> to be in getting different parts of the "Inter"-net to "inter"-work. >> The >> last months of QoS and, now, NAT, on the mail list make me believe >> that >> getting a call across multiple IP networks may not be as easy as one >> big >> 'blob', and it really needs to be shown as multiple 'little blobs'. > > An all IP (with no CSN) packet flow (with or without) separate control > planes needed to be named within this WG - this document does this in > its > simplest form. While I agree generally that it will not likely be the > case > that an actual IEPREP call/session be placed only over a single IP > provider, it is a slippery slope in establishing (or ASCII drawing) > something that represents the e2e IP topology in multi-domain > scenarios. > The Internet is implied to be a series of loosely connected IP > domains. Are > you asking that this be explicitly stated in section 2.4 for clarity? I agree with Pat. The document needs to make it VERY clear that the typical scenario for any traffic across the global Internet involves more than one ISP and several different administrative domains. A minimalist example along these lines would look something like this: Source Domain ("A") Source's ISP ("B") Destination's ISP ("C") Destination Domain ("D") The document should also make clear that each of these 4 administrative domains is able to have their own policies and configurations -- and typically each domain's policies and practices WILL be somewhat different from the others. The document should also explicitly note that both NAT and Firewalls are common in many end-user (i.e. non-ISP) domains -- so end-to-end transparency is currently not always the case (i.e. not a good assumption in general) for the deployed global Internet. We need for these aspects of the deployed reality to be very clear so that folks don't erroneously think that the deployed situation is simpler than it is. Cheers, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 3 14:56:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17772 for ; Fri, 3 Jan 2003 14:56:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03K5gp20807 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 15:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03K5fJ20804 for ; Fri, 3 Jan 2003 15:05:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17753 for ; Fri, 3 Jan 2003 14:56:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03K42J20768; Fri, 3 Jan 2003 15:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03K3XJ20739 for ; Fri, 3 Jan 2003 15:03:33 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17733 for ; Fri, 3 Jan 2003 14:54:07 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id h03JvBql002037; Fri, 3 Jan 2003 14:57:11 -0500 (EST) Date: Fri, 3 Jan 2003 14:57:11 -0500 (EST) From: Scott Bradner Message-Id: <200301031957.h03JvBql002037@newdev.harvard.edu> To: jmpolk@cisco.com, rja@extremenetworks.com Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Cc: ieprep@ietf.org, pcain@genuity.com In-Reply-To: Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , the purpose of the document is to define terminology I do not think it is needed to overload it with a description of the Internet Scott ---- From ieprep-admin@ietf.org Fri Jan 3 14:52:38 2003 Date: Fri, 3 Jan 2003 14:51:28 -0500 Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "pat cain" , To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20030102180247.033e7240@localhost> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , On Thursday, Jan 2, 2003, at 19:12 America/Montreal, James M. Polk wrote: > At 06:18 PM 1/2/2003 -0500, pat cain wrote: >> 2. The four scenarios sound right, but I had problems with section 2.4 >> "End-to-End-IP". >> The picture in 2.4 shows the IP Network as one big blob -- which I >> interpret >> (probably incorrectly) as one network provider. I think this is the >> easy >> scenario. I would suggest that the one blob be shown as two little >> blobs >> with an interconnection, as I expect most of the scenario busters are >> going >> to be in getting different parts of the "Inter"-net to "inter"-work. >> The >> last months of QoS and, now, NAT, on the mail list make me believe >> that >> getting a call across multiple IP networks may not be as easy as one >> big >> 'blob', and it really needs to be shown as multiple 'little blobs'. > > An all IP (with no CSN) packet flow (with or without) separate control > planes needed to be named within this WG - this document does this in > its > simplest form. While I agree generally that it will not likely be the > case > that an actual IEPREP call/session be placed only over a single IP > provider, it is a slippery slope in establishing (or ASCII drawing) > something that represents the e2e IP topology in multi-domain > scenarios. > The Internet is implied to be a series of loosely connected IP > domains. Are > you asking that this be explicitly stated in section 2.4 for clarity? I agree with Pat. The document needs to make it VERY clear that the typical scenario for any traffic across the global Internet involves more than one ISP and several different administrative domains. A minimalist example along these lines would look something like this: Source Domain ("A") Source's ISP ("B") Destination's ISP ("C") Destination Domain ("D") The document should also make clear that each of these 4 administrative domains is able to have their own policies and configurations -- and typically each domain's policies and practices WILL be somewhat different from the others. The document should also explicitly note that both NAT and Firewalls are common in many end-user (i.e. non-ISP) domains -- so end-to-end transparency is currently not always the case (i.e. not a good assumption in general) for the deployed global Internet. We need for these aspects of the deployed reality to be very clear so that folks don't erroneously think that the deployed situation is simpler than it is. Cheers, Ran rja@extremenetworks.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 mailnull@www1.ietf.org Fri Jan 3 15:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18377 for ; Fri, 3 Jan 2003 15:25:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03KYUO22511 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 15:34:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KYUJ22506 for ; Fri, 3 Jan 2003 15:34:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18351 for ; Fri, 3 Jan 2003 15:25:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KX2J22447; Fri, 3 Jan 2003 15:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KWxJ22430 for ; Fri, 3 Jan 2003 15:32:59 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18329 for ; Fri, 3 Jan 2003 15:23:33 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 3 Jan 2003 15:25:57 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003010315262831753 ; Fri, 03 Jan 2003 15:26:28 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 15:28:09 -0500 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Cc: "'sob@harvard.edu'" , "'jmpolk@cisco.com'" Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Date: Fri, 3 Jan 2003 15:26:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Scott said: >the purpose of the document is to define terminology >I do not think it is needed to overload it with a >description of the Internet I agree. The idea has come up of renaming the document with a title that more clearly defines its objective (e.g., "IEPREP Telephony Interworking Terminology"). Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 3 15:27:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18417 for ; Fri, 3 Jan 2003 15:27:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03KaLN22609 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 15:36:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KaKJ22606 for ; Fri, 3 Jan 2003 15:36:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18413 for ; Fri, 3 Jan 2003 15:26:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KZ2J22568; Fri, 3 Jan 2003 15:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KYlJ22535 for ; Fri, 3 Jan 2003 15:34:47 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18357 for ; Fri, 3 Jan 2003 15:25:18 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id h03KSJ1k002181; Fri, 3 Jan 2003 15:28:19 -0500 (EST) Date: Fri, 3 Jan 2003 15:28:19 -0500 (EST) From: Scott Bradner Message-Id: <200301032028.h03KSJ1k002181@newdev.harvard.edu> To: ieprep@ietf.org, KIMBERLY.S.KING@saic.com Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Cc: jmpolk@cisco.com, sob@harvard.edu In-Reply-To: Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , note also that this doc has already been passed from teh WG to the IESG which has OKed its publication pending a name change Scott -- From KIMBERLY.S.KING@saic.com Fri Jan 3 15:26:57 2003 From: "King, Kimberly S." To: "'ieprep@ietf.org'" Cc: "'sob@harvard.edu'" , "'jmpolk@cisco.com'" Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Date: Fri, 3 Jan 2003 15:26:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Scott said: >the purpose of the document is to define terminology >I do not think it is needed to overload it with a >description of the Internet I agree. The idea has come up of renaming the document with a title that more clearly defines its objective (e.g., "IEPREP Telephony Interworking Terminology"). Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 3 15:32:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18500 for ; Fri, 3 Jan 2003 15:32:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03Kfam23487 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 15:41:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KfaJ23484 for ; Fri, 3 Jan 2003 15:41:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18494 for ; Fri, 3 Jan 2003 15:32:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03Ke4J23437; Fri, 3 Jan 2003 15:40:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KddJ23393 for ; Fri, 3 Jan 2003 15:39:39 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18444 for ; Fri, 3 Jan 2003 15:30:12 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 2EFC567103; Fri, 3 Jan 2003 15:37:26 -0500 (EST) Date: Fri, 3 Jan 2003 15:33:21 -0500 Subject: Re: [Ieprep] Revised Topologies ID for WG consideration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: jmpolk@cisco.com, ieprep@ietf.org, pcain@genuity.com To: Scott Bradner From: RJ Atkinson In-Reply-To: <200301031957.h03JvBql002037@newdev.harvard.edu> Message-Id: <99E10DE0-1F5A-11D7-B8F0-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Jan 3, 2003, at 14:57 America/Montreal, Scott Bradner wrote: > the purpose of the document is to define terminology Scott, The above is NOT at all clear from the current document -- precisely because it does in fact talk at length about "topologies" with an implication that they are real-world topologies of the Internet. > I do not think it is needed to overload it with a description of the > Internet It already has an description of the Internet. Are you proposing to delete that ? The proposal a couple of us have made is to clarify the description so that it is more accurate/complete. If you don't want to clarify the topologies as a couple of us have suggested, then at minimum add a specific clear disclaimer that the document does NOT describe actual real-world topologies present in the Internet, but instead is only defining particular words (working from the above assertion that the purpose is to "define terminology"). Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 3 19:12:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22206 for ; Fri, 3 Jan 2003 19:12:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h040Luk03693 for ieprep-archive@odin.ietf.org; Fri, 3 Jan 2003 19:21:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040LuJ03690 for ; Fri, 3 Jan 2003 19:21:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22202 for ; Fri, 3 Jan 2003 19:12:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040KFJ03656; Fri, 3 Jan 2003 19:20:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040JfJ03603 for ; Fri, 3 Jan 2003 19:19:41 -0500 Received: from kc-msxproto4.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22131 for ; Fri, 3 Jan 2003 19:10:10 -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.5329); Fri, 3 Jan 2003 18:13:22 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 3 Jan 2003 18:13:21 -0600 Message-ID: Thread-Topic: What Do You Recommend? Thread-Index: AcKzhhdZaR2MV8+cQOmfCQ98pyqkPw== From: "Beard, Cory" To: X-OriginalArrivalTime: 04 Jan 2003 00:13:22.0442 (UTC) FILETIME=[17B36EA0:01C2B386] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h040JfJ03604 Subject: [Ieprep] What Do You Recommend? Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have a simple question I was asking myself as I went through the latest postings here. But I could not decide how some of you would answer this question, so I will just ask. What Internet-based applications/communications tools do you recommend that emergency response workers (in general, federal or local) use as part of their standard operating procedures using existing protocols? IM? E-mail? VoIP? Web? Video? GIS/database applications? Wireless versions of these? Keep in mind that by "standard operating procedures" I mean those that are "in the manual". Anyone trained to be an emergency worker would be trained to follow these procedures. Local response organizations would be instructed to follow these procedures and buy the equipment to do them. These procedures would be important to follow because of efficiency of operation (i.e., lives might be at stake) and the safety of the workers. People cannot waste time with a communications tool that may or may not work. The reason I ask is that for some services/applications I am not sure if some of you would say "use the Internet, it is plenty reliable" or if you would say "do not plan to use the Internet, because the reliability is impossible to control because of all of the devices and organizations involved." Remember, the whole goal here is to expand the capabilities of emergency workers to use Internet-based tools to save lives. Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 4 17:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16626 for ; Sat, 4 Jan 2003 17:06:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04MFfv11396 for ieprep-archive@odin.ietf.org; Sat, 4 Jan 2003 17:15:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04MFfJ11393 for ; Sat, 4 Jan 2003 17:15:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16612 for ; Sat, 4 Jan 2003 17:05:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04MDUJ11342; Sat, 4 Jan 2003 17:13:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04MCqJ11327 for ; Sat, 4 Jan 2003 17:12:52 -0500 Received: from cam-po2.genuity.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16597 for ; Sat, 4 Jan 2003 17:02:54 -0500 (EST) Received: from pcain2000 (wob-vpn252-080.genuity.com [171.78.252.80]) by cam-po2.genuity.com (8.11.3/8.11.2) with SMTP id h04M65B12418; Sat, 4 Jan 2003 17:06:05 -0500 (EST) From: "pat cain" To: "Beard, Cory" Cc: Subject: RE: [Ieprep] What Do You Recommend? Date: Sat, 4 Jan 2003 17:05:57 -0500 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.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cory, It's impossible to answer this question using the term 'emergency worker'. Many 'emergency workers' are 'first responders' (aka, fire, ems, bomb squad) and are already self-contained or have adequate communications systems. Other 'emergency workers' (aka FEMA, Civil defense) are mostly coordinators and directors and require different communications depending on their location and purpose. Note that Kimberly's data gathering from various places has not identified a trend. To make his on-topic for ieprep, I expect that there are many emergency workers that will not benefit from our efforts in this WG. Other workers may be ecstatic. Pat > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of > Beard, Cory > Sent: Friday, January 03, 2003 7:13 PM > To: ieprep@ietf.org > Subject: [Ieprep] What Do You Recommend? > > > I have a simple question I was asking myself as I went through > the latest postings here. But I could not decide how some of you > would answer this question, so I will just ask. > > What Internet-based applications/communications tools do you > recommend that emergency response workers (in general, federal or > local) use as part of their standard operating procedures using > existing protocols? IM? E-mail? VoIP? Web? Video? GIS/database > applications? Wireless versions of these? > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 4 18:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17137 for ; Sat, 4 Jan 2003 18:17:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04NQaW14014 for ieprep-archive@odin.ietf.org; Sat, 4 Jan 2003 18:26:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04NQaJ14011 for ; Sat, 4 Jan 2003 18:26:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17134 for ; Sat, 4 Jan 2003 18:16:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04NP5J13985; Sat, 4 Jan 2003 18:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04NOuJ13964 for ; Sat, 4 Jan 2003 18:24:56 -0500 Received: from kc-msxproto4.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17124 for ; Sat, 4 Jan 2003 18:14:57 -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.5329); Sat, 4 Jan 2003 17:18:10 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] What Do You Recommend? Date: Sat, 4 Jan 2003 17:18:10 -0600 Message-ID: Thread-Topic: [Ieprep] What Do You Recommend? Thread-Index: AcK0PZl0HElNHj4tRKCzMXzfcIls5wAAduEw From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "pat cain" , "Beard, Cory" Cc: X-OriginalArrivalTime: 04 Jan 2003 23:18:10.0251 (UTC) FILETIME=[8BE4F1B0:01C2B447] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h04NOuJ13965 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > I expect that there are many emergency workers that > will not benefit from our efforts in this WG. One cannot ask all the emergency responders to use Internet. Even if they want to, there are lot of other issues other than just technology and standardization..policy (govt and ISP policies), pricing, deployment, contract and business issues (which IETF have no say.) Its worth pointing that many things cannot be changed if they don't bring revenue. I remember quoting the following Mike o' Dell lines to many: http://www.cs.washington.edu/hotnets/papers/fernandez.pdf "Mike O'Dell said: [to have a Voice-over-IP service network one has to] create the most expensive data service to run an application for which people are willing to pay less money everyday, [...] and for which telephony already provides a better solution with a marginal cost of almost zero." I guess, current users of GETS might find SIP resource priority header standardization very useful. So, IMO, if at some point an emergency responder or service provider want to use Internet, they can look into the bcp -which should elaborate on Kimberly's two mails regarding emergency scenarios..with more information on * Use of last mile access and metropolitan technologies...like IEEE 802.11 QoS, packet ring 802.17 etc. * Use of policy agents like BB and marking policy. * Problems in first mile ..crowding at the web servers etc. Coming to the topic under discussion, we can provide some guidelines for the standard operating procedures used by emergency responders...namely possible disaster communication applications and associated guidelines.. TRIP based routing, overlay routing schmes (not network level), use of independent application protocols like BEEP etc. It should also detail on the use of systems like IAA (Ran wrote a detailed mail regarding its use.) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 7 10:40:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18712 for ; Tue, 7 Jan 2003 10:40:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07Fpcn29750 for ieprep-archive@odin.ietf.org; Tue, 7 Jan 2003 10:51:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FpcJ29747 for ; Tue, 7 Jan 2003 10:51:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18678 for ; Tue, 7 Jan 2003 10:40:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FnSJ29639; Tue, 7 Jan 2003 10:49:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FmZJ29564 for ; Tue, 7 Jan 2003 10:48:35 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18602 for ; Tue, 7 Jan 2003 10:37:18 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 7 Jan 2003 10:39:44 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003010710401727660 for ; Tue, 07 Jan 2003 10:40:17 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 10:40:02 -0500 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Tue, 7 Jan 2003 10:40:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07FmZJ29565 Subject: [Ieprep] Internet Dependency and Education for Emergency Organizations--request comments Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit How can we can do more for Internet Emergency Preparedness? I want to share my idea with you and see what you think. In essence, the idea is to create a BCP for emergency organizations (e.g., hospitals) to help them to understand the importance of understanding their dependency upon the Internet. (We aren't done with VoIP and congestion management; this is a complementary idea perhaps for the back burner.) Example of why this is needed: In "The Internet Under Crisis Conditions: Learning from September 11", we learned that several hospitals provide doctors with wireless access to hospital databases. However, unknown to the hospitals that outsourced the service, this system had dependencies on Internet links. Thus wireless access to internal databases may be lost if their Internet connection to their wireless carrier fails. Had they been more educated, they could have known what to ask about and done something to reduce their vulnerability (e.g., an additional access link). http://zoom.nap.edu/nap-cgi/rezoom.cgi?isbn=0309087023&page=21 Here's more on the same theme... http://www.ncs.gov/nstac/NSTACXXII/Reports/Internet.pdf "NSTAC Recommendations to the President · Recommend that the President, in accordance with responsibilities and existing Mechanisms established by Executive Order 12472, Assignment of National Security And Emergency Preparedness Telecommunications Functions, direct the Establishment of a permanent program to address NS/EP issues related to the Internet. The program should have the following objectives: - Work with the NS/EP community to increase understanding of Evolving Internet dependencies by a. Evaluating the extent of their current and future direct and indirect Dependence on the public Internet for NS/EP mission-critical Operations b. Developing a thorough understanding of their physical intranet architectures and connections to the public Internet in order to identify and protect against potential vulnerabilities c. Developing plans and programs to implement long-term goals related to NS/EP dependence on the public Internet d. Defining Internet security and reliability requirements needed to support NS/EP operations. Although current NS/EP community dependence on the public Internet is modest, dependence on TCP/IP intranets is more extensive. As agencies and organizations consider and adopt additional applications that increase their dependence on the Internet and intranets, it will become increasingly important to assess the extent of this dependence and to determine potential consequences resulting from Internet disruptions. The NS/EP community will need to be more aware of the physical topology of individual networks to understand how dependence on the Internet may affect network operations. It is also important that the NS/EP community determine Internet reliability and availability requirements needed to support NS/EP services and operations and subsequently develop plans and programs necessary to implement longterm goals for increased dependence on the Internet." Anybody have ideas about this concept? How it could be modified to be more useful? Do people think it is useful? Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 7 19:12:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04707 for ; Tue, 7 Jan 2003 19:12:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080NKm30633 for ieprep-archive@odin.ietf.org; Tue, 7 Jan 2003 19:23:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080NKJ30630 for ; Tue, 7 Jan 2003 19:23:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04670 for ; Tue, 7 Jan 2003 19:11:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080L8J30480; Tue, 7 Jan 2003 19:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080HKJ30283 for ; Tue, 7 Jan 2003 19:17:20 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04432 for ; Tue, 7 Jan 2003 19:05:52 -0500 (EST) Received: from extremenetworks.com (unknown [10.0.8.104]) by gnat.inet.org (Postfix) with ESMTP id C1D1F67106 for ; Tue, 7 Jan 2003 19:13:54 -0500 (EST) Date: Tue, 7 Jan 2003 19:09:05 -0500 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit Message-Id: <668E2217-229D-11D7-9AA2-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [Ieprep] Internet on 9/11/01 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks might want to see the current issue of IEEE Spectrum, in which there is an article by Dave Farber on pages 51-52. The article's focus is not on IEprep, but rather on cybersecurity. An applicable partial quote: "[The Internet] was also the best way to contact family and friends in the northeast United States, as the telephone system overloaded, in part because of the destruction of a key installation at Ground Zero that handled local and cellular service." Note that Dave Farber is a former Chief Technologist at the US FCC, who regulate communications in the US. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 9 09:26:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11087 for ; Thu, 9 Jan 2003 09:26:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Ebpn26846 for ieprep-archive@odin.ietf.org; Thu, 9 Jan 2003 09:37:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EbpJ26843 for ; Thu, 9 Jan 2003 09:37:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11076 for ; Thu, 9 Jan 2003 09:25:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Ea8J26095; Thu, 9 Jan 2003 09:36:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EZgJ26057 for ; Thu, 9 Jan 2003 09:35:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10799; Thu, 9 Jan 2003 09:23:28 -0500 (EST) Message-Id: <200301091423.JAA10799@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: Thu, 09 Jan 2003 09:23:27 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-general-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : General Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-general-00.txt Pages : 9 Date : 2003-1-8 This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-general-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-ietf-ieprep-ets-general-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-ietf-ieprep-ets-general-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: <2003-1-9092322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-general-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-general-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092322.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 9 09:26:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11090 for ; Thu, 9 Jan 2003 09:26:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Ebqp26861 for ieprep-archive@odin.ietf.org; Thu, 9 Jan 2003 09:37:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EbqJ26858 for ; Thu, 9 Jan 2003 09:37:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11078 for ; Thu, 9 Jan 2003 09:25:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EaLJ26153; Thu, 9 Jan 2003 09:36:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EZmJ26062 for ; Thu, 9 Jan 2003 09:35:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10817; Thu, 9 Jan 2003 09:23:33 -0500 (EST) Message-Id: <200301091423.JAA10817@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: Thu, 09 Jan 2003 09:23:33 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-00.txt Pages : 5 Date : 2003-1-8 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. Solutions to these requirements are not presented in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-telephony-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-ietf-ieprep-ets-telephony-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-ietf-ieprep-ets-telephony-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: <2003-1-9092330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-telephony-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092330.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 9 09:36:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11840 for ; Thu, 9 Jan 2003 09:36:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Em0d27533 for ieprep-archive@odin.ietf.org; Thu, 9 Jan 2003 09:48:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Em0J27528 for ; Thu, 9 Jan 2003 09:48:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11724 for ; Thu, 9 Jan 2003 09:35:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Ek2J27391; Thu, 9 Jan 2003 09:46:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EjmJ27363 for ; Thu, 9 Jan 2003 09:45:48 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11423 for ; Thu, 9 Jan 2003 09:33:33 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 9 Jan 2003 09:36:02 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003010909363516287 for ; Thu, 09 Jan 2003 09:36:35 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 09:38:19 -0500 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Thu, 9 Jan 2003 09:36:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] rational problem solving Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Bruce Schneier has a five step process for thinking about security measures but actually the process is general and applies to ieprep problems. 1) What problem does it solve? 2) How well does it solve the problem? 3) What new problems does it add? 4) What are the economic and social costs? 5) Given the above, is it worth the costs? http://www.counterpane.com/presentation4.pdf Does anyone see a concrete particular ieprep problem that needs to be solved? If you are reluctant to write in public, feel free to email off the list. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 9 13:04:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19336 for ; Thu, 9 Jan 2003 13:04:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IG6w11188 for ieprep-archive@odin.ietf.org; Thu, 9 Jan 2003 13:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IG6J11185 for ; Thu, 9 Jan 2003 13:16:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19321 for ; Thu, 9 Jan 2003 13:03:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IE8J11095; Thu, 9 Jan 2003 13:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IDgJ11068 for ; Thu, 9 Jan 2003 13:13:42 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19290 for ; Thu, 9 Jan 2003 13:01:23 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id h09HwAo19915; Thu, 9 Jan 2003 09:58:10 -0800 (PST) Date: Thu, 9 Jan 2003 09:58:10 -0800 (PST) From: Bill Woodcock To: "King, Kimberly S." cc: "Ieprep (E-mail)" Subject: Re: [Ieprep] rational problem solving In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > Does anyone see a concrete particular ieprep problem that needs to be > solved? 1) In cases in which one can plug a phone into a network _and get a globally routed IP address via DHCP_, can a call actually be placed to an arbitrary other phone? I'm not wording this well, but basically what I'm getting at is the basic issue of reachability through NATs/firewalls. If you can't get an IP address in the first place, that's a whole different problem, and one which standards and legislation and so forth aren't going to fix. But once you've got that, can you actually call your destination, or is a NAT in front of the destination going to block the call because it doesn't know how to deal with it? That's our number one problem right now. 2) When the receiving-end phone gets an emergency call, right now it doesn't know anything special about the call. Can we cryptographically authenticate the "emergency" nature of the call, so that the receiving-end phone can do things like up its ring volume, use a different ring-tone, do a call-waiting beep on the line during an already-off-hook call, et cetera? -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 10 21:06:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22514 for ; Fri, 10 Jan 2003 21:06:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B2J8x13648 for ieprep-archive@odin.ietf.org; Fri, 10 Jan 2003 21:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B2J8J13645 for ; Fri, 10 Jan 2003 21:19:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22502 for ; Fri, 10 Jan 2003 21:06:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B2HUJ13600; Fri, 10 Jan 2003 21:17:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALaYJ30625 for ; Fri, 10 Jan 2003 16:36:34 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16771 for ; Fri, 10 Jan 2003 16:23:41 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18X6g3-0008CN-00; Fri, 10 Jan 2003 13:26:55 -0800 To: "King, Kimberly S." cc: "'ieprep@ietf.org'" Subject: Re: [Ieprep] SIP requirements draft after WG last call In-Reply-To: Message from "King, Kimberly S." of "Mon, 02 Dec 2002 17:34:12 EST." Date: Fri, 10 Jan 2003 13:26:55 -0800 From: Allison Mankin Message-Id: Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Hi, Folks, We on the IESG approved draft-ietf-ietf-sip-reqs-03 during the IESG call on Thursday. I had some review issues with it that did not require holding it up, but which did result in the following RFC Editor note. You'll see this note in the announcement Monday: RFC Editor Note: Before REQ-1 insert the following paragraph: Note: not all the following requirements are possible to meet at once. They may represent in some cases tradeoffs that must be considered by the designer. I'm fairly confident that folks should be ok with the above. It was stimulated by conflict between the the requirement for proxy visibility (REQ-17) and confidentiality etc. (SEC-8 and SEC-9), one of the two issues I recorded in the id-tracker and passed on to the author but did not block the draft about. The other issue goes to the future work with the doc. The issue is realism about common expression of the emergency namespace/routing etc. Three requirements presented expectations of high understanding across heterogeneous domains (REQ-4, 5 and 7), and this struck me as a very high expectation, but now SIPPING can consider what technology supports the requirements. Anyway, good news, and thanks for the hard work! Allison _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Jan 13 11:30:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15905 for ; Mon, 13 Jan 2003 11:30:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DGi3U04857 for ieprep-archive@odin.ietf.org; Mon, 13 Jan 2003 11:44:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DGi3J04854 for ; Mon, 13 Jan 2003 11:44:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15889 for ; Mon, 13 Jan 2003 11:29:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DGgFJ04795; Mon, 13 Jan 2003 11:42:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DGfUJ04762 for ; Mon, 13 Jan 2003 11:41:30 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15816 for ; Mon, 13 Jan 2003 11:27:16 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Mon, 13 Jan 2003 11:26:03 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003011311263508351 for ; Mon, 13 Jan 2003 11:26:35 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 11:26:20 -0500 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Mon, 13 Jan 2003 11:26:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] SIP Operation in the Public Internet: What Makes Running it a Challenge and What it Takes to Deal With It Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , http://www.nanog.org/mtg-0302/jiri.html Also, available relatively soon...it's typical for the presentation (and sometimes video) to be available on the web. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Jan 13 15:32:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23121 for ; Mon, 13 Jan 2003 15:32:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKkgf21149 for ieprep-archive@odin.ietf.org; Mon, 13 Jan 2003 15:46:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKkgJ21146 for ; Mon, 13 Jan 2003 15:46:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23097 for ; Mon, 13 Jan 2003 15:32:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKjCJ21089; Mon, 13 Jan 2003 15:45:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKihJ21043 for ; Mon, 13 Jan 2003 15:44:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22978; Mon, 13 Jan 2003 15:30:24 -0500 (EST) Message-Id: <200301132030.PAA22978@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ieprep@ietf.org From: The IESG Date: Mon, 13 Jan 2003 15:30:24 -0500 Subject: [Ieprep] Document Action: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol to Informational Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Requirements for Resource Priority Mechanisms for the Session Initiation Protocol' as an Informational RFC. This document is the product of the Internet Emergency Preparedness Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. RFC Editor Note: Before REQ-1 insert the following paragraph: Note: not all the following requirements are possible to meet at once. They may represent in some cases tradeoffs that must be considered by the designer. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 14 00:18:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05281 for ; Tue, 14 Jan 2003 00:18:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E5W2m19865 for ieprep-archive@odin.ietf.org; Tue, 14 Jan 2003 00:32:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5W2J19862 for ; Tue, 14 Jan 2003 00:32:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05277 for ; Tue, 14 Jan 2003 00:17:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5UCJ19793; Tue, 14 Jan 2003 00:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5TBJ19751 for ; Tue, 14 Jan 2003 00:29:11 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05262 for ; Tue, 14 Jan 2003 00:14:42 -0500 (EST) Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 23:18:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 13 Jan 2003 23:18:01 -0600 Message-ID: Thread-Topic: Operating on a "war footing" (was Re: Violation of Acceptable Use Policies) Thread-Index: AcK7i71xndB0lwReSdyjB7qZiKeqzgAAEUiA From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: X-OriginalArrivalTime: 14 Jan 2003 05:18:02.0411 (UTC) FILETIME=[4F8AD7B0:01C2BB8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E5TBJ19752 Subject: [Ieprep] FW: Operating on a "war footing" (was Re: Violation of Acceptable Use Policies) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Monday, January 13, 2003 11:14 PM To: Simon Lyall Cc: nanog@merit.edu Subject: Operating on a "war footing" (was Re: Violation of Acceptable Use Policies) On Sun, 12 Jan 2003, Simon Lyall wrote: > ObOperational: Does anyone have a pointer to "war footing" practices? > Things like gaving prepared links to News websites, reduced maintenance, > rumor control and the like? As reported at the Sprint 2002 NANOG I was the working group lead for the ISP disaster recovery working group. We prepared a document on steps ISPs should take in preparation for a disaster, but its not generally available. However, the paper really didn't contain any surprises. Around the world ISPs have learned how to operate in the middle of wars and unrest over the last 10 years. B92 in the former Yugoslavia was one of the more vocal ISPs operating during a military conflict. EUnet and other ISPs were also active through much of the conflict. There are several other continuing conflicts around the world which don't reach the level of full scale military action. One of the few publically available documents about operating a public network during a disaster is ANSI T1.202-1998 Internetwork Operations Guidelines for Network Management of the Public Switched Networks under Disaster Conditions These guidelines encompass the cooperative intercompany network management actions (that may be) required during emergency conditions associated with disasters that threaten life or property and cause congestion in the public switched networks (PSNs). Network management actions should optimize the integrity of the PSNs while obtaining the maximum use of the network capability during a disaster condition. These guidelines address the network actions required to relieve congestion in the PSN caused by failures resulting from the disaster conditions. Examples of disaster conditions that would benefit from these guidelines are: natural disasters (such as hurricanes, earthquakes, floods, and the like), major accidents (such as transportation, industrial, or environmental), or civil disturbances (such as terrorist acts or other similar events). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 16 11:20:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15095 for ; Thu, 16 Jan 2003 11:20:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGa9X02272 for ieprep-archive@odin.ietf.org; Thu, 16 Jan 2003 11:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGa9J02269 for ; Thu, 16 Jan 2003 11:36:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15066 for ; Thu, 16 Jan 2003 11:20:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGYRJ02086; Thu, 16 Jan 2003 11:34:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGU8J01884 for ; Thu, 16 Jan 2003 11:30:08 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14940 for ; Thu, 16 Jan 2003 11:14:25 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 16 Jan 2003 11:16:52 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003011611172821282 for ; Thu, 16 Jan 2003 11:17:28 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 11:17:13 -0500 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Thu, 16 Jan 2003 11:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GGU8J01885 Subject: [Ieprep] Megaco Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi! Anybody want to investigate how Megaco can be used to support preferential treatment for certain calls (e.g., emergency services not limited to 911)? Part of what would be nice to understand is does a priority indicator need to be the Megaco protocol or could preferential treatment be done based upon something the MGC understands? Here is a specific example. With the GETS service in the circuit-switched world, a PSTN switch will allow a GETS call a greater chance of success by giving it a larger timeout window to obtain a trunk. Now suppose we are in some kind of IP Bridging scenario and a MGC receive a SS7 message for setting up a GETS call. (The part of SS7 that GETS uses for conveying priority is a codepoint in the CPC of the IAM.) Can a MGC do a similar thing of allowing some small interval for a gateway port to become available before returning a fast busy or something like that? If so, this doesn't seem to require any Megaco protocol changes and I believe MGC's could have access to multiple gateways and hence even poll other gateways (in addition to trying the same gateway again later) based upon policy. This would provide both queuing for resources and alternate routing. Plus, it isn't dependent upon the gateways which I think are fairly diverse in the number of vendors/gateways/etc. With this solution, the gateways themselves would have to understand no priority indicator or do anything about it. Alternatively, is this kind of timeout (if performed at all) done in the gateway whereby perhaps Megaco would need to pass some priority indicator? This solution might involve a Megaco protocol change (see below), would potentially be more difficult to implement because MG and MGC would have to understand the indicator and act upon it. Etc. Related questions: 1. Can a MG have certain assets (e.g., ports) reserved exclusively for emergency services where the indicator triggers the MG's use of this asset? 2. Is there anything to forbid an MGC from tracking priority of on-going calls (e.g., MLPP scenario) and pre-empting calls using gateway resources? 3. Is the Boolean emergency indication reserved for 911? Could a MG be setup to place certain policy_data elements within an associated RSVP request for transport of IP media when it receives either a certain priority or emergency indicator? Background: The framework http://www.ietf.org/rfc/rfc2805.txt states " k. Allow the MGC to specify that a given connection has higher priority than other connections." 6.1.1 Context attributes and descriptors of http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt "ò The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of Contexts must be handled simultaneously. Priority 0 is the lowest priority and a priority of 15 is the highest priority. ò An indicator for an emergency call is also provided to allow a preference handling in the MG." Ideas? Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 16 13:04:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18484 for ; Thu, 16 Jan 2003 13:04:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIJSd10928 for ieprep-archive@odin.ietf.org; Thu, 16 Jan 2003 13:19:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIJSJ10925 for ; Thu, 16 Jan 2003 13:19:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18440 for ; Thu, 16 Jan 2003 13:03:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GII5J10805; Thu, 16 Jan 2003 13:18:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIHIJ10742 for ; Thu, 16 Jan 2003 13:17:18 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18383 for ; Thu, 16 Jan 2003 13:01:35 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 16 Jan 2003 10:05:04 +0000 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA22682; Thu, 16 Jan 2003 10:04:53 -0800 (PST) Message-Id: <4.3.2.7.2.20030116111901.020e2c28@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Jan 2003 12:06:50 -0600 To: "King, Kimberly S." , "Ieprep (E-mail)" From: "James M. Polk" Subject: Re: [Ieprep] Megaco In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GIHIJ10743 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit At 11:17 AM 1/16/2003 -0500, King, Kimberly S. wrote: >Hi! > >Anybody want to investigate how Megaco can be used to support >preferential treatment for certain calls (e.g., emergency >services not limited to 911)? > >Part of what would be nice to understand is does a priority >indicator need to be the Megaco protocol or could >preferential treatment be done based upon something >the MGC understands? In a scenario in which a single MGC controls both GWs from the CSN, SS7 should be able to provide the MGC enough information to not allow the next available trunk to become free to anyone (internal MGC decision - not a protocol issue). If the call leg is hung up (meaning the dial user disconnects the line or hangs up the phone), the SUBTRACT command is sent from the GW to the MGC, with the MGC then configuring this ETS-waiting trunk through the IP cloud (if and ) once an egress MG port becomes available in the appropriate path. I don't believe MEGACO/H.248 needs adjusting in this scenario. If the above scenario is expanded in such a way as there are two MGCs controlling different GWs, this will require a Peer-to-Peer protocol communication between MGCs - which is not MEGACO/H.248. Therefore, MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling protocol does - because none are capable today for this notification out of MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe SIP-T is generally planned between MGCs, is it? It's either SIP or BICC, I believe. I don't believe there will be a need for protocol extension in the case where endpoints are not multiport MGs (RFC 3054), as this would fall under the guidelines of the above (with the MGC controlling all incoming and outgoing control messages). All GETS authentication and authorization will occur via the dial-pad and therefore go through the MGC. There might be something within the protocol that communicates out the MGC into the CSN for this authentication and authorization (SIGTRAN?) - but I don't believe that will be MEGACO/H.248 And preemption shouldn't change the protocol either, as the SUBTRACT command should accomplish this behavior quite well. >Here is a specific example. With the GETS service in the >circuit-switched world, a PSTN switch will allow a GETS call >a greater chance of success by giving it a larger timeout >window to obtain a trunk. Now suppose we are in some kind of >IP Bridging scenario and a MGC receive a SS7 message for >setting up a GETS call. (The part of SS7 that GETS uses for >conveying priority is a codepoint in the CPC of the IAM.) >Can a MGC do a similar thing of allowing some small interval >for a gateway port to become available before returning a >fast busy or something like that? The MGC should control everything about an MG under its control except for 1 command (NOTIFY - which should be applicable in this case) and part of another (SUBTRACT - which is used appropriately in this case). >If so, this doesn't seem to require any >Megaco protocol changes and >I believe MGC's could have access to multiple >gateways and hence even poll other gateways >(in addition to trying the same gateway again later) >based upon policy. This would provide both >queuing for resources and alternate routing. >Plus, it isn't dependent upon the gateways which >I think are fairly diverse in the number of >vendors/gateways/etc. With this solution, the >gateways themselves would have to understand >no priority indicator or do anything about it. I don't believe priority indication matters in a Client/Server control protocol such as this >Alternatively, is this kind of timeout >(if performed at all) done in the gateway >whereby perhaps Megaco would need to pass >some priority indicator? Only two commands go from the GW to the MGC (NOTIFY and SUBTRACT). I believe these should solve what you're looking for. >This solution might involve a Megaco protocol >change (see below), would potentially be more >difficult to implement because MG and MGC >would have to understand the indicator and >act upon it. Etc. > >Related questions: > >1. Can a MG have certain assets (e.g., ports) reserved >exclusively for emergency services where the >indicator triggers the MG's use of this asset? IAM commands go to the MGC, not the MG. Trunk access is done through the ADD, MOVE and MODIFY commands in MEGACO/H.248. A (RFC 3054) termination uses the NOTIFY command to an MGC to inform it that device is starting something (like dialing digits - that are mapped to a digit map for call routing) >2. Is there anything to forbid an MGC from tracking >priority of on-going calls (e.g., MLPP scenario) >and pre-empting calls using gateway resources? Ahhh - MLPP and preemption changes things. There must be a something like an MLPP Package created (through some ITU/IETF documents) indicating what precedence values are allowed (I think this is only partially handled in H.248v2). AUDITVALUE and AUDITCAPABILITIES commands will be needed by the MGC to determine an MGs status and future capabilities. A NOTIFY command, as part of the digit map, or as a separate command will be needed for the user to convey which precedence level they wish engaged for that call (especially in the 3054 scenario) >3. Is the Boolean emergency indication reserved for 911? NENA doesn't want preemption, so this is a call routing issue within the MGC to the outbound GW towards the appropriate PSAP. >Could a MG be setup to place certain policy_data >elements within an associated RSVP request for >transport of IP media when it receives either a >certain priority or emergency indicator? Ask Tom Taylor (MEGACO Chair) >Background: > >The framework http://www.ietf.org/rfc/rfc2805.txt states " > k. Allow the MGC to specify that a given connection has higher > priority than other connections." > >6.1.1 Context attributes and descriptors of > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt > "ò The priority is used for a Context in order to provide > the MG with >information about a certain precedence handling for a Context. The >MGC can also use the priority to control autonomously the traffic >precedence in the MG in a smooth way in certain situations (e.g. >restart), when a lot of Contexts must be handled simultaneously. >Priority 0 is the lowest priority and a priority of 15 is >the highest priority. > >ò An indicator for an emergency call is also provided to allow a >preference handling in the MG." This should be part of the digit map, and internal queuing, not a protocol issue for 911 issues. >Ideas? > >Kimberly >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 16 13:46:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20160 for ; Thu, 16 Jan 2003 13:46:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJ1kc14190 for ieprep-archive@odin.ietf.org; Thu, 16 Jan 2003 14:01:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ1kJ14187 for ; Thu, 16 Jan 2003 14:01:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20146 for ; Thu, 16 Jan 2003 13:46:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ04J14101; Thu, 16 Jan 2003 14:00:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIxvJ14062 for ; Thu, 16 Jan 2003 13:59:57 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20116 for ; Thu, 16 Jan 2003 13:44:12 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 16 Jan 2003 13:46:40 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003011613471406194 ; Thu, 16 Jan 2003 13:47:14 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 13:46:59 -0500 Message-Id: From: "King, Kimberly S." To: "'James M. Polk '" , "'King, Kimberly S. '" , "'Ieprep (E-mail) '" Cc: "'jon.peterson@neustar.biz'" Subject: RE: [Ieprep] Megaco Date: Thu, 16 Jan 2003 13:47:14 -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-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Thanks James, this is excellent. >If the above scenario is expanded in such a way as there are two MGCs >controlling different GWs, this will require a Peer-to-Peer protocol >communication between MGCs - which is not MEGACO/H.248. Therefore, >MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling >protocol does - because none are capable today for this notification out >of >MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe >SIP-T is generally planned between MGCs, is it? It's either SIP or BICC, >I believe. When I was talking with the "softswitch" type vendors, many indicated they would use SIP-T between their MGCs. SIP-T would encapsulate the HPC as part of the ISUP so I suppose it depends upon whether the other MGC de-codes this information. Since SIP-T is really SIP tailored for telephony, I would hope that any new mechanism that SIPPING produces for the Resource Priority Header would be compatible with SIP-T. That way, if the MGC's don't look at encapsulated information, they would be a way to convey emergency communications in this architecture. Maybe Jon will help us out...pretty please. :-) Kimberly -----Original Message----- From: James M. Polk To: King, Kimberly S.; Ieprep (E-mail) Sent: 1/16/2003 1:06 PM Subject: Re: [Ieprep] Megaco At 11:17 AM 1/16/2003 -0500, King, Kimberly S. wrote: >Hi! > >Anybody want to investigate how Megaco can be used to support >preferential treatment for certain calls (e.g., emergency >services not limited to 911)? > >Part of what would be nice to understand is does a priority >indicator need to be the Megaco protocol or could >preferential treatment be done based upon something >the MGC understands? In a scenario in which a single MGC controls both GWs from the CSN, SS7 should be able to provide the MGC enough information to not allow the next available trunk to become free to anyone (internal MGC decision - not a protocol issue). If the call leg is hung up (meaning the dial user disconnects the line or hangs up the phone), the SUBTRACT command is sent from the GW to the MGC, with the MGC then configuring this ETS-waiting trunk through the IP cloud (if and ) once an egress MG port becomes available in the appropriate path. I don't believe MEGACO/H.248 needs adjusting in this scenario. If the above scenario is expanded in such a way as there are two MGCs controlling different GWs, this will require a Peer-to-Peer protocol communication between MGCs - which is not MEGACO/H.248. Therefore, MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling protocol does - because none are capable today for this notification out of MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe SIP-T is generally planned between MGCs, is it? It's either SIP or BICC, I believe. I don't believe there will be a need for protocol extension in the case where endpoints are not multiport MGs (RFC 3054), as this would fall under the guidelines of the above (with the MGC controlling all incoming and outgoing control messages). All GETS authentication and authorization will occur via the dial-pad and therefore go through the MGC. There might be something within the protocol that communicates out the MGC into the CSN for this authentication and authorization (SIGTRAN?) - but I don't believe that will be MEGACO/H.248 And preemption shouldn't change the protocol either, as the SUBTRACT command should accomplish this behavior quite well. >Here is a specific example. With the GETS service in the >circuit-switched world, a PSTN switch will allow a GETS call >a greater chance of success by giving it a larger timeout >window to obtain a trunk. Now suppose we are in some kind of >IP Bridging scenario and a MGC receive a SS7 message for >setting up a GETS call. (The part of SS7 that GETS uses for >conveying priority is a codepoint in the CPC of the IAM.) >Can a MGC do a similar thing of allowing some small interval >for a gateway port to become available before returning a >fast busy or something like that? The MGC should control everything about an MG under its control except for 1 command (NOTIFY - which should be applicable in this case) and part of another (SUBTRACT - which is used appropriately in this case). >If so, this doesn't seem to require any >Megaco protocol changes and >I believe MGC's could have access to multiple >gateways and hence even poll other gateways >(in addition to trying the same gateway again later) >based upon policy. This would provide both >queuing for resources and alternate routing. >Plus, it isn't dependent upon the gateways which >I think are fairly diverse in the number of >vendors/gateways/etc. With this solution, the >gateways themselves would have to understand >no priority indicator or do anything about it. I don't believe priority indication matters in a Client/Server control protocol such as this >Alternatively, is this kind of timeout >(if performed at all) done in the gateway >whereby perhaps Megaco would need to pass >some priority indicator? Only two commands go from the GW to the MGC (NOTIFY and SUBTRACT). I believe these should solve what you're looking for. >This solution might involve a Megaco protocol >change (see below), would potentially be more >difficult to implement because MG and MGC >would have to understand the indicator and >act upon it. Etc. > >Related questions: > >1. Can a MG have certain assets (e.g., ports) reserved >exclusively for emergency services where the >indicator triggers the MG's use of this asset? IAM commands go to the MGC, not the MG. Trunk access is done through the ADD, MOVE and MODIFY commands in MEGACO/H.248. A (RFC 3054) termination uses the NOTIFY command to an MGC to inform it that device is starting something (like dialing digits - that are mapped to a digit map for call routing) >2. Is there anything to forbid an MGC from tracking >priority of on-going calls (e.g., MLPP scenario) >and pre-empting calls using gateway resources? Ahhh - MLPP and preemption changes things. There must be a something like an MLPP Package created (through some ITU/IETF documents) indicating what precedence values are allowed (I think this is only partially handled in H.248v2). AUDITVALUE and AUDITCAPABILITIES commands will be needed by the MGC to determine an MGs status and future capabilities. A NOTIFY command, as part of the digit map, or as a separate command will be needed for the user to convey which precedence level they wish engaged for that call (especially in the 3054 scenario) >3. Is the Boolean emergency indication reserved for 911? NENA doesn't want preemption, so this is a call routing issue within the MGC to the outbound GW towards the appropriate PSAP. >Could a MG be setup to place certain policy_data >elements within an associated RSVP request for >transport of IP media when it receives either a >certain priority or emergency indicator? Ask Tom Taylor (MEGACO Chair) >Background: > >The framework http://www.ietf.org/rfc/rfc2805.txt states " > k. Allow the MGC to specify that a given connection has higher > priority than other connections." > >6.1.1 Context attributes and descriptors of > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt > "ò The priority is used for a Context in order to provide > the MG with >information about a certain precedence handling for a Context. The >MGC can also use the priority to control autonomously the traffic >precedence in the MG in a smooth way in certain situations (e.g. >restart), when a lot of Contexts must be handled simultaneously. >Priority 0 is the lowest priority and a priority of 15 is >the highest priority. > >ò An indicator for an emergency call is also provided to allow a >preference handling in the MG." This should be part of the digit map, and internal queuing, not a protocol issue for 911 issues. >Ideas? > >Kimberly >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 16 13:59:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20657 for ; Thu, 16 Jan 2003 13:59:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJEdh15452 for ieprep-archive@odin.ietf.org; Thu, 16 Jan 2003 14:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJEdJ15449 for ; Thu, 16 Jan 2003 14:14:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20585 for ; Thu, 16 Jan 2003 13:58:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJD2J15361; Thu, 16 Jan 2003 14:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJCcJ15332 for ; Thu, 16 Jan 2003 14:12:38 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20466 for ; Thu, 16 Jan 2003 13:56:54 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 16 Jan 2003 13:59:25 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003011614000017075 ; Thu, 16 Jan 2003 14:00:00 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 14:01:47 -0500 Message-Id: From: "King, Kimberly S." To: "'James M. Polk '" , "'King, Kimberly S. '" , "'Ieprep (E-mail) '" Subject: RE: [Ieprep] Megaco (Correction) Date: Thu, 16 Jan 2003 14:00:00 -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-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Opps! I said "I would hope that any new mechanism that SIPPING produces for the Resource Priority Header would be compatible with SIP-T." Delete the word "Header" out of that line. I was thinking of old drafts but a header isn't the only way to provide the functionality requested in the "Requirements for Resource Priority Mechanisms for the SIP". Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 17 13:01:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00158 for ; Fri, 17 Jan 2003 13:01:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HIHRC19401 for ieprep-archive@odin.ietf.org; Fri, 17 Jan 2003 13:17:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIHRJ19398 for ; Fri, 17 Jan 2003 13:17:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00142 for ; Fri, 17 Jan 2003 13:01:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HICUJ19113; Fri, 17 Jan 2003 13:12:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI3WJ18040 for ; Fri, 17 Jan 2003 13:03:32 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29703 for ; Fri, 17 Jan 2003 12:47:20 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 17 Jan 2003 09:50:34 +0000 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA09716 for ; Fri, 17 Jan 2003 09:50:40 -0800 (PST) Message-Id: <4.3.2.7.2.20030217114355.044bc240@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 11:52:38 -0600 To: ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Fwd: I-D ACTION:draft-polk-ieprep-flow-model-considerations-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , I've just published this new ID on the differences in the paths taken by control plane signaling packets and data plane packets. There are various diagram examples within. This ID is not intended to be all inclusive to the IETF, but covering IEPREP related protocols. Comments on this ieprep list are appreciated (or to me directly if you feel that is more appropriate) >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-polk-ieprep-flow-model-considerations-00.txt >Date: Thu, 16 Jan 2003 08:05:50 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Considerations for IEPREP Related Protocol > Packet Flow > Models > Author(s) : J. Polk > Filename : draft-polk-ieprep-flow-model-considerations-00.txt > Pages : 8 > Date : 2003-1-15 > >This document diagrams the packet flows - both signaling and data - of >Internet Emergency Preparedness (IEPREP) related protocols. This document >serves as a point of reference for the WG when discussing if (and which) >QoS mechanisms should be employed for each individual (application) protocol >packet flow to function properly during congestion events from IP source >to IP >destination. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-ieprep-flow-model-considerations-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-polk-ieprep-flow-model-considerations-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-polk-ieprep-flow-model-considerations-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. >Content-Type: text/plain >Content-ID: <2003-1-15125619.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-polk-ieprep-flow-model-considerations-00.txt > > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 17 15:19:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03537 for ; Fri, 17 Jan 2003 15:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HKZaK27317 for ieprep-archive@odin.ietf.org; Fri, 17 Jan 2003 15:35:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HKZaJ27314 for ; Fri, 17 Jan 2003 15:35:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03527 for ; Fri, 17 Jan 2003 15:19:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HKX7J27245; Fri, 17 Jan 2003 15:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HKWoJ27214 for ; Fri, 17 Jan 2003 15:32:50 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03501 for ; Fri, 17 Jan 2003 15:16:34 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0HKJZ825915; Fri, 17 Jan 2003 20:19:35 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 15:22:11 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D18@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'King, Kimberly S.'" , "'James M. Polk '" , "'Ieprep (E-mail) '" Subject: RE: [Ieprep] Megaco Date: Fri, 17 Jan 2003 15:22:09 -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-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , A brief note inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] > Sent: Thursday, January 16, 2003 10:47 AM > To: 'James M. Polk '; 'King, Kimberly S. '; 'Ieprep (E-mail) ' > Cc: 'jon.peterson@neustar.biz' > Subject: RE: [Ieprep] Megaco > > > Thanks James, this is excellent. > > >If the above scenario is expanded in such a way as there are two MGCs > >controlling different GWs, this will require a Peer-to-Peer protocol > >communication between MGCs - which is not MEGACO/H.248. Therefore, > >MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling > >protocol does - because none are capable today for this notification out of > >MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe > >SIP-T is generally planned between MGCs, is it? It's either SIP or BICC, > >I believe. > > When I was talking with the "softswitch" type vendors, many indicated they > would use SIP-T between their MGCs. SIP-T would encapsulate the HPC as part > of the ISUP so I suppose it depends upon whether the other MGC de-codes this > information. Since SIP-T is really SIP tailored for telephony, I would hope > that any new mechanism that SIPPING produces for the Resource Priority > Header would be compatible with SIP-T. That way, if the MGC's don't look at > encapsulated information, they would be a way to convey emergency > communications in this architecture. > > Maybe Jon will help us out...pretty please. :-) > I think you're correct, Kimberly, that the intended application of SIP-T (at least the ISUP encapsulation mechanism defined in RFC3204) is MGC-to-MGC communication employing SIP. Essentially, all ISUP parameters will be passed transparently from the ingress MGC to the egress MGC, and they should be usable normally as ISUP (provided the ingress and egress MGC speak compatible ISUP variants). So, in my opinion, sharing priority information between MGCs over SIP could be addressed by our existing work. > > Kimberly > > -----Original Message----- > From: James M. Polk > To: King, Kimberly S.; Ieprep (E-mail) > Sent: 1/16/2003 1:06 PM > Subject: Re: [Ieprep] Megaco > > At 11:17 AM 1/16/2003 -0500, King, Kimberly S. wrote: > >Hi! > > > >Anybody want to investigate how Megaco can be used to support > >preferential treatment for certain calls (e.g., emergency > >services not limited to 911)? > > > >Part of what would be nice to understand is does a priority > >indicator need to be the Megaco protocol or could > >preferential treatment be done based upon something > >the MGC understands? > > In a scenario in which a single MGC controls both GWs from > the CSN, SS7 > should be able to provide the MGC enough information to not allow the > next > available trunk to become free to anyone (internal MGC > decision - not a > protocol issue). If the call leg is hung up (meaning the dial user > disconnects the line or hangs up the phone), the SUBTRACT command is > sent > from the GW to the MGC, with the MGC then configuring this > ETS-waiting > trunk through the IP cloud (if and ) once an egress MG port becomes > available in the appropriate path. > > I don't believe MEGACO/H.248 needs adjusting in this scenario. > > If the above scenario is expanded in such a way as there are two MGCs > controlling different GWs, this will require a Peer-to-Peer protocol > communication between MGCs - which is not MEGACO/H.248. Therefore, > MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling > protocol does - because none are capable today for this > notification out > of > MAYBE the recent effort by Jon Peterson with SIP-T. But I > don't believe > SIP-T is generally planned between MGCs, is it? It's either > SIP or BICC, > I > believe. > > I don't believe there will be a need for protocol extension > in the case > where endpoints are not multiport MGs (RFC 3054), as this would fall > under > the guidelines of the above (with the MGC controlling all > incoming and > outgoing control messages). > > All GETS authentication and authorization will occur via the dial-pad > and > therefore go through the MGC. There might be something within the > protocol > that communicates out the MGC into the CSN for this > authentication and > authorization (SIGTRAN?) - but I don't believe that will be > MEGACO/H.248 > > And preemption shouldn't change the protocol either, as the SUBTRACT > command should accomplish this behavior quite well. > > > >Here is a specific example. With the GETS service in the > >circuit-switched world, a PSTN switch will allow a GETS call > >a greater chance of success by giving it a larger timeout > >window to obtain a trunk. Now suppose we are in some kind of > >IP Bridging scenario and a MGC receive a SS7 message for > >setting up a GETS call. (The part of SS7 that GETS uses for > >conveying priority is a codepoint in the CPC of the IAM.) > >Can a MGC do a similar thing of allowing some small interval > >for a gateway port to become available before returning a > >fast busy or something like that? > > The MGC should control everything about an MG under its control except > for > 1 command (NOTIFY - which should be applicable in this case) > and part of > > another (SUBTRACT - which is used appropriately in this case). > > > >If so, this doesn't seem to require any > >Megaco protocol changes and > >I believe MGC's could have access to multiple > >gateways and hence even poll other gateways > >(in addition to trying the same gateway again later) > >based upon policy. This would provide both > >queuing for resources and alternate routing. > >Plus, it isn't dependent upon the gateways which > >I think are fairly diverse in the number of > >vendors/gateways/etc. With this solution, the > >gateways themselves would have to understand > >no priority indicator or do anything about it. > > I don't believe priority indication matters in a > Client/Server control > protocol such as this > > > >Alternatively, is this kind of timeout > >(if performed at all) done in the gateway > >whereby perhaps Megaco would need to pass > >some priority indicator? > > Only two commands go from the GW to the MGC (NOTIFY and SUBTRACT). I > believe these should solve what you're looking for. > > > >This solution might involve a Megaco protocol > >change (see below), would potentially be more > >difficult to implement because MG and MGC > >would have to understand the indicator and > >act upon it. Etc. > > > >Related questions: > > > >1. Can a MG have certain assets (e.g., ports) reserved > >exclusively for emergency services where the > >indicator triggers the MG's use of this asset? > > IAM commands go to the MGC, not the MG. Trunk access is done > through the > > ADD, MOVE and MODIFY commands in MEGACO/H.248. A (RFC 3054) > termination > uses the NOTIFY command to an MGC to inform it that device is > starting > something (like dialing digits - that are mapped to a digit > map for call > > routing) > > > >2. Is there anything to forbid an MGC from tracking > >priority of on-going calls (e.g., MLPP scenario) > >and pre-empting calls using gateway resources? > > Ahhh - MLPP and preemption changes things. There must be a something > like > an MLPP Package created (through some ITU/IETF documents) indicating > what > precedence values are allowed (I think this is only partially > handled in > > H.248v2). AUDITVALUE and AUDITCAPABILITIES commands will be needed by > the > MGC to determine an MGs status and future capabilities. A NOTIFY > command, > as part of the digit map, or as a separate command will be needed for > the > user to convey which precedence level they wish engaged for that call > (especially in the 3054 scenario) > > > >3. Is the Boolean emergency indication reserved for 911? > > NENA doesn't want preemption, so this is a call routing issue > within the > > MGC to the outbound GW towards the appropriate PSAP. > > > >Could a MG be setup to place certain policy_data > >elements within an associated RSVP request for > >transport of IP media when it receives either a > >certain priority or emergency indicator? > > Ask Tom Taylor (MEGACO Chair) > > > > >Background: > > > >The framework http://www.ietf.org/rfc/rfc2805.txt states " > > k. Allow the MGC to specify that a given connection has higher > > priority than other connections." > > > >6.1.1 Context attributes and descriptors of > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt > > "ò The priority is used for a Context in order to provide > > the MG with > >information about a certain precedence handling for a Context. The > >MGC can also use the priority to control autonomously the traffic > >precedence in the MG in a smooth way in certain situations (e.g. > >restart), when a lot of Contexts must be handled simultaneously. > >Priority 0 is the lowest priority and a priority of 15 is > >the highest priority. > > > >ò An indicator for an emergency call is also provided to allow a > >preference handling in the MG." > > This should be part of the digit map, and internal queuing, not a > protocol > issue for 911 issues. > > > >Ideas? > > > >Kimberly > >_______________________________________________ > >Ieprep mailing list > >Ieprep@ietf.org > >https://www1.ietf.org/mailman/listinfo/ieprep > > > cheers, > James > > ************************************* > "People generally demand more respect for their own rights than > they are willing to allow for others" > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 18 17:14:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02209 for ; Sat, 18 Jan 2003 17:14:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0IMULw15711 for ieprep-archive@odin.ietf.org; Sat, 18 Jan 2003 17:30:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0IMULJ15708 for ; Sat, 18 Jan 2003 17:30:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02203 for ; Sat, 18 Jan 2003 17:13:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0IMSSJ15646; Sat, 18 Jan 2003 17:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0IMRSJ15604 for ; Sat, 18 Jan 2003 17:27:28 -0500 Received: from kc-msxproto4.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02132 for ; Sat, 18 Jan 2003 17:10:40 -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.5329); Sat, 18 Jan 2003 16:14:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 18 Jan 2003 16:14:03 -0600 Message-ID: Thread-Topic: [Ieprep] Fwd: I-D ACTION:draft-polk-ieprep-flow-model-considerations-00.txt Thread-Index: AcK+Ujx0eJRbSJuUTyCYgvi1/BivBAA66JFg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "James M. Polk" , X-OriginalArrivalTime: 18 Jan 2003 22:14:04.0588 (UTC) FILETIME=[E97BD6C0:01C2BF3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0IMRSJ15605 Subject: [Ieprep] RE:polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Comments on this ieprep list are appreciated 1/ I really like the draft. Its very crisp and provides a good classification of application level data/control plane. I might be missing something very basic. But, I fail to understand how the draft serves as a point of reference for the WG when discussing *if (and which) QoS mechanisms* should be employed for each individual (application) protocol packet flow. My understanding of application-level signaling is that it helps in differentiating various applications. The quality of service part (network level) will remain the same whether we are going to use in-band or out-of-band /receiver-initiated or source-initiated signaling. An ISP can provide some kind of static provisioning (best effort) or network level signaling (RSVP) to support the application depending on their service features. So, how does your draft helps in identifying whether the application has to use QoS or not? Do you mean to say, " Since the draft has classified the application level stuff used for ieprep, one can infer whether those application require QoS mechanisms based on their known delay/jitter requirements." 2/ The draft has not mentioned RTSP and SAP. Is that media-on-demand and broadcast applications are not useful for ieprep? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 21 07:56:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27853 for ; Tue, 21 Jan 2003 07:56:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LDDYu15193 for ieprep-archive@odin.ietf.org; Tue, 21 Jan 2003 08:13:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDDYJ15183 for ; Tue, 21 Jan 2003 08:13:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27841 for ; Tue, 21 Jan 2003 07:55:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDBmJ15061; Tue, 21 Jan 2003 08:11:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDAbJ14937 for ; Tue, 21 Jan 2003 08:10:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27659; Tue, 21 Jan 2003 07:52:34 -0500 (EST) Message-Id: <200301211252.HAA27659@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, 21 Jan 2003 07:52:34 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-01.txt Pages : 5 Date : 2003-1-20 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. Solutions to these requirements are not presented in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-telephony-01.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-ietf-ieprep-ets-telephony-01.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-ietf-ieprep-ets-telephony-01.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: <2003-1-20131736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-telephony-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-20131736.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 21 07:56:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27875 for ; Tue, 21 Jan 2003 07:56:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LDE1X15231 for ieprep-archive@odin.ietf.org; Tue, 21 Jan 2003 08:14:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDE1J15228 for ; Tue, 21 Jan 2003 08:14:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27848 for ; Tue, 21 Jan 2003 07:55:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDBdJ15024; Tue, 21 Jan 2003 08:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDAPJ14924 for ; Tue, 21 Jan 2003 08:10:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27625; Tue, 21 Jan 2003 07:52:22 -0500 (EST) Message-Id: <200301211252.HAA27625@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, 21 Jan 2003 07:52:21 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-03.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Framework for Supporting IEPS in IP Telephony Author(s) : K. Carlberg, I. Brown Filename : draft-ietf-ieprep-framework-03.txt Pages : 27 Date : 2003-1-20 This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-03.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-ietf-ieprep-framework-03.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-ietf-ieprep-framework-03.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: <2003-1-20131716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-20131716.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 21 08:36:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29514 for ; Tue, 21 Jan 2003 08:36:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LDrjk18036 for ieprep-archive@odin.ietf.org; Tue, 21 Jan 2003 08:53:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDrjJ18033 for ; Tue, 21 Jan 2003 08:53:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29509 for ; Tue, 21 Jan 2003 08:35:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDpxJ17919; Tue, 21 Jan 2003 08:51:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDoUJ17838 for ; Tue, 21 Jan 2003 08:50:30 -0500 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29297 for ; Tue, 21 Jan 2003 08:32:24 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Jan 2003 13:35:45 +0000 To: ieprep@ietf.org Date: Tue, 21 Jan 2003 13:35:43 +0000 Message-ID: <29571.1043156143@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] ieprep drafts Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , hi, as you will have seen in your morning email box, there are three new versions of IEPREP drafts: 2 requirements, and 1 framework. version -01 of the Requirements drafts are very similar to -00. a couple of minor clarifications were added in response to some email from Kimberly. I'd like to ask for final round of discussion on these drafts for those on the list that may have any new concerns. my hope is that we have reached rough consensus and a measure of comprise on previous discussions. if there are no new issues, then with luck we can request a last call on the Requirements drafts. as for the Framework draft, a number of changes have been made. the highlights include: 1. changing the title of the document from IEPS to ETS based telephony, since other documents (and the general discussion) has gravitated to the term ETS 2. replaced the phrase "functional requirements" with the term "protocol and capabilities". as those of you who are on the IEPREP mailing list have seen, the word "requirement" incurs a fair amount of indigestion with some folks :-)...so i've changed the phrase, and pretty much removed the word requirement from the draft 3. added pointers to the recent Requirements documents that have been accepted as working group items by the Chairs. I've also added a pointer to Polk's topology draft and Henning's SIP Requirements draft (there is no RFC number assigned yet, so I'll update the draft accordingly at a later date). 4. I've removed suggested augmentations to TRIP and the SIP R-P header draft of Polk. Allyson Mankin was concerned it looked too much like a solution. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Jan 21 08:42:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27852 for ; Tue, 21 Jan 2003 07:56:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LDDYm15180 for ieprep-archive@odin.ietf.org; Tue, 21 Jan 2003 08:13:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDDYJ15177 for ; Tue, 21 Jan 2003 08:13:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27839 for ; Tue, 21 Jan 2003 07:55:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDBlJ15045; Tue, 21 Jan 2003 08:11:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDAUJ14931 for ; Tue, 21 Jan 2003 08:10:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27642; Tue, 21 Jan 2003 07:52:27 -0500 (EST) Message-Id: <200301211252.HAA27642@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, 21 Jan 2003 07:52:27 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-general-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : General Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-general-01.txt Pages : 9 Date : 2003-1-20 This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-general-01.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-ietf-ieprep-ets-general-01.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-ietf-ieprep-ets-general-01.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: <2003-1-20131726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-general-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-general-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-20131726.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 23 13:18:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15635 for ; Thu, 23 Jan 2003 13:18:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NIbXf14516 for ieprep-archive@odin.ietf.org; Thu, 23 Jan 2003 13:37:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIbXJ14513 for ; Thu, 23 Jan 2003 13:37:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15609 for ; Thu, 23 Jan 2003 13:18:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIZQJ13766; Thu, 23 Jan 2003 13:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIYSJ13699 for ; Thu, 23 Jan 2003 13:34:28 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15463 for ; Thu, 23 Jan 2003 13:15:19 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 23 Jan 2003 13:17:50 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003012313183011489 ; Thu, 23 Jan 2003 13:18:30 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 13:20:19 -0500 Message-Id: From: "King, Kimberly S." To: "James Polk (E-mail)" Cc: "Ieprep (E-mail)" Date: Thu, 23 Jan 2003 13:18:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] draft-polk-ieprep-flow-model-considerations-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Hi James, I was a bit confused by the classification of FTP as out-of-band signaling in http://www.ietf.org/internet-drafts/draft-polk-ieprep-flow-model-considerati ons-00.txt. The text and picture show an Intermediary Server and I'm not sure what this would be in the case of FTP. Maybe the text could make it clear there doesn't have to be an Intermediary Server or am I missing something? (I realized that you classified FTP as out-of-band because data and signaling use different ports.) Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 23 17:48:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22793 for ; Thu, 23 Jan 2003 17:48:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NN6n832578 for ieprep-archive@odin.ietf.org; Thu, 23 Jan 2003 18:06:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NN6mJ32575 for ; Thu, 23 Jan 2003 18:06:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22778 for ; Thu, 23 Jan 2003 17:47:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NN57J32471; Thu, 23 Jan 2003 18:05:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NN4nJ32445 for ; Thu, 23 Jan 2003 18:04:49 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22718 for ; Thu, 23 Jan 2003 17:45:34 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 23 Jan 2003 14:49:16 +0000 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA17554; Thu, 23 Jan 2003 14:48:55 -0800 (PST) Message-Id: <4.3.2.7.2.20030123163744.04c6e058@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 16:48:49 -0600 To: "King, Kimberly S." From: "James M. Polk" Cc: "Ieprep (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Re: draft-polk-ieprep-flow-model-considerations-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 01:18 PM 1/23/2003 -0500, King, Kimberly S. wrote: >Hi James, > >I was a bit confused by the classification of FTP >as out-of-band signaling in >http://www.ietf.org/internet-drafts/draft-polk-ieprep-flow-model-considerati >ons-00.txt. >The text and picture show an Intermediary Server >and I'm not sure what this would be in the case of FTP. No it wouldn't with binary choices. But the definition of In-Band control is stated as between the source and destination IP addresses, the same port number is used. Out-of-Band control has either the IP addresses different from the data plane endpoints (like SIP), or the port numbers are different than the data plane src/dest endpoints. FTP uses ports 20 and 21, even though the source and destination IP address is the same as the data plane. I can offer changing the document to include diagrams (showing) and text (explaining) that the Server could be external to the destination endpoint in one Figure (a), and the other Figure (b) the server is logically different than the data endpoint (though with the same IP address). Will this be satisfactory? >Maybe the text could make it clear there doesn't have >to be an Intermediary Server or am I missing something? >(I realized that you classified FTP as out-of-band >because data and signaling use different ports.) > >Kimberly cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Jan 23 18:20:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23993 for ; Thu, 23 Jan 2003 18:20:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NNcsO03134 for ieprep-archive@odin.ietf.org; Thu, 23 Jan 2003 18:38:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNcsJ03131 for ; Thu, 23 Jan 2003 18:38:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23970 for ; Thu, 23 Jan 2003 18:19:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNbGJ02738; Thu, 23 Jan 2003 18:37:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNafJ02345 for ; Thu, 23 Jan 2003 18:36:41 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23900 for ; Thu, 23 Jan 2003 18:17:27 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 23 Jan 2003 15:21:09 +0000 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA21479; Thu, 23 Jan 2003 15:20:52 -0800 (PST) Message-Id: <4.3.2.7.2.20030123164923.04c768e8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 17:20:48 -0600 To: "Ayyasamy, Senthilkumar (UMKC-Student)" , From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE:polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 04:14 PM 1/18/2003 -0600, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > Comments on this ieprep list are appreciated > >1/ I really like the draft. Its very crisp and provides a good >classification of application level data/control plane. I might >be missing something very basic. But, I fail to understand >how the draft serves as a point of reference for the WG when >discussing *if (and which) QoS mechanisms* should be employed >for each individual (application) protocol packet flow. I don't want to step in *it* too deep here, but there have been discussions that have merged all combinations of Data Plane with the two Control Planes as if they are to be treated in the same manner. I thought this short ID could serve as educator/reminder of sorts to reduce this occurrence in the future. >My understanding of application-level signaling is that it helps in >differentiating various applications. The quality of service part >(network level) will remain the same whether we are going to use >in-band or out-of-band /receiver-initiated or source-initiated >signaling. Taking your statement at face value, I *could* read into it that (for example) SIP signaling is to have the same treatment (if there is any in the first place) as RTP. I think few would actually agree with this as a general rule. RTP has delay/jitter tolerances that are far more sensitive to that Protocol's normal operation than does SIP or MGCP or MEGACO/H.248 messages. >An ISP can provide some kind of static provisioning >(best effort) or network level signaling (RSVP) to support the >application depending on their service features. Would a SIP "INVITE" or a MEGACO "ADD" need RSVP to be successfully received by its intended destination? But one could argue fairly successfully that an RTP stream justifies RSVP usage under many circumstances. >So, how does your >draft helps in identifying whether the application has to use >QoS or not? I hope it helps demonstrate that there are different flows traversing different paths, allowing the reader to know to isolate their efforts on any one flow or path at a time - and not group too many of them together. >Do you mean to say, " Since the draft has classified >the application level stuff used for ieprep, one can infer whether >those application require QoS mechanisms based on their known >delay/jitter requirements." This is certainly one of several inferences that I would like a reader to conclude. There is at least one more document I want to write as the next logical step of this document - which will hopefully target your comment quoted just above more directly. I felt this document was required first. >2/ The draft has not mentioned RTSP and SAP. Is that media-on-demand >and broadcast applications are not useful for ieprep? I didn't mention a protocol that hasn't appeared on the list yet, I just did a search again to reconfirm that neither SAP or RTSP have yet (according to my mail program). I'm sure though that I left a few protocols that have been mentioned out, and want feedback to that affect. I'll look to the group and chairs for guidance as to whether to include either or both SAP and RTSP in this document. It certainly wouldn't take much, but I also want to be conscious of having the list of protocols included not get too large and off track for IEPREP's mission. Thank you for the feedback cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 24 06:44:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16127 for ; Fri, 24 Jan 2003 06:44:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OC3p324696 for ieprep-archive@odin.ietf.org; Fri, 24 Jan 2003 07:03:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OC3pJ24693 for ; Fri, 24 Jan 2003 07:03:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16104 for ; Fri, 24 Jan 2003 06:44:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OC2HJ24535; Fri, 24 Jan 2003 07:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OBuXJ24288 for ; Fri, 24 Jan 2003 06:56:33 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15973 for ; Fri, 24 Jan 2003 06:37:05 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 24 Jan 2003 06:39:39 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003012406402031742 ; Fri, 24 Jan 2003 06:40:20 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 06:42:10 -0500 Message-Id: From: "King, Kimberly S." To: "'James M. Polk '" , "'King, Kimberly S. '" Cc: "'Ieprep (E-mail) '" Date: Fri, 24 Jan 2003 06:40:19 -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: draft-polk-ieprep-flow-model-considerations-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , James said: >I can offer changing the document to include diagrams (showing) >and text (explaining) that the Server could be external to >the destination endpoint in one Figure (a), and the other >Figure (b) the server is logically different than the data endpoint >(though with the same IP address). >Will this be satisfactory? Yes, that would be fine with me. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 24 17:02:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03671 for ; Fri, 24 Jan 2003 17:02:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OMLCI01013 for ieprep-archive@odin.ietf.org; Fri, 24 Jan 2003 17:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMLCJ01010 for ; Fri, 24 Jan 2003 17:21:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03662 for ; Fri, 24 Jan 2003 17:01:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMJBJ00919; Fri, 24 Jan 2003 17:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMIPJ00890 for ; Fri, 24 Jan 2003 17:18:25 -0500 Received: from kc-msxproto4.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03595 for ; Fri, 24 Jan 2003 16:58:42 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.111] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 16:02:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 Jan 2003 16:02:09 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02CF35@KC-MAIL4.kc.umkc.edu> Thread-Topic: polk-ieprep-flow-model-considerations-00 Thread-Index: AcLDNhQqdPtIn+vZTpm2wGY9KNM10wAt/DoQ From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "James M. Polk" , X-OriginalArrivalTime: 24 Jan 2003 22:02:10.0481 (UTC) FILETIME=[3E524210:01C2C3F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0OMIPJ00891 Subject: [Ieprep] RE: polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > >1/ I really like the draft. Its very crisp and provides a good > >classification of application level data/control plane. I might > >be missing something very basic. But, I fail to understand > >how the draft serves as a point of reference for the WG when > >discussing *if (and which) QoS mechanisms* should be employed > >for each individual (application) protocol packet flow. > > I don't want to step in *it* too deep here, but there have > been discussions that have merged all combinations of Data > Plane with the two Control Planes as if they are > to be treated in the same manner. I thought this short ID > could serve as educator/reminder of sorts to reduce this > occurrence in the future. we can discuss and write spec on *which* QoS mechanism can be used. But, not *if* QoS mechanism should be employed. Their is no study to prove that QoS/provisioning is better than the other. We can keep debating on either side of the fence. Their are strong arguments on why QoS is not necessary and why it is necessary for whatever reason. So, > >Do you mean to say, " Since the draft has classified > >the application level stuff used for ieprep, one can infer whether > >those application require QoS mechanisms based on their known > >delay/jitter requirements." > > > There is at least one more document I want to write as the > next logical step of this document - which will hopefully > target your comment quoted just above more directly. the follow-up draft can provide us guidelines based on both the scenarios: - If I use best-effort, what are the things to be done for creating an end to end ieprep service. Three of Kimberly's mail regarding scenarios and one of rogan's mail on data center will serve as a major input. - If I use QoS models, what are the things to be done for creating an end to end ieprep service. An obvious approach will be mapping your application level classification with Fred's ieprep-packet-marking-policy. But, some text have to be added for explaining inter-domain signaling methods. - It should also mention about various ieprep services that may be helpful for emergency responders. For example, effective use of systems like IAA ( Ran's mail.) > >My understanding of application-level signaling is that it helps in > >differentiating various applications. The quality of service part ^^^^^^^^^^^^^^^^^^^^^^^ > >(network level) will remain the same whether we are going to use > >in-band or out-of-band /receiver-initiated or source-initiated > >signaling. > > Taking your statement at face value, I *could* read into it that (for > example) SIP signaling is to have the same treatment (if > there is any in the first place) as RTP. I did not mean that way. I meant *quality of service component* (like Diffserv) rather than the actual quality measure (like delay/jitter.)in the above quoted text. If you take the quality measure, it differs depending on the application requirements. > > I think few would actually agree with this as a general rule. I can even argue the other way round. what if I give high-priority to the scavenger traffic(if its my own intranet.) So, they are more of policy issues. > RTP has delay/jitter tolerances that are far more sensitive to that > Protocol's normal operation than does SIP or MGCP or MEGACO/H.248 > messages. > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 24 19:22:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06201 for ; Fri, 24 Jan 2003 19:22:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P0fRh08640 for ieprep-archive@odin.ietf.org; Fri, 24 Jan 2003 19:41:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0fRJ08637 for ; Fri, 24 Jan 2003 19:41:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06195 for ; Fri, 24 Jan 2003 19:21:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0e9J08583; Fri, 24 Jan 2003 19:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0dsJ08536 for ; Fri, 24 Jan 2003 19:39:54 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06185 for ; Fri, 24 Jan 2003 19:20:10 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 24 Jan 2003 16:23:46 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA20343; Fri, 24 Jan 2003 16:23:36 -0800 (PST) Message-Id: <4.3.2.7.2.20030124174258.0241b358@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 17:50:08 -0600 To: "Ayyasamy, Senthilkumar (UMKC-Student)" , From: "James M. Polk" In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02CF35@KC-MAIL4.kc.umkc.ed u> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Good comments - I will consider them when focusing on the next effort. For this ID, you aren't uncomfortable with the phrase "...if (and which) QoS mechanisms..." What would you prefer for this part of the text: #1 - "...if QoS mechanisms..." or #2 - "...which QoS mechanisms..." or another short piece of text, or remove the phrase and relevant text surrounding it? At 04:02 PM 1/24/2003 -0600, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > >1/ I really like the draft. Its very crisp and provides a good > > >classification of application level data/control plane. I might > > >be missing something very basic. But, I fail to understand > > >how the draft serves as a point of reference for the WG when > > >discussing *if (and which) QoS mechanisms* should be employed > > >for each individual (application) protocol packet flow. > > > > I don't want to step in *it* too deep here, but there have > > been discussions that have merged all combinations of Data > > Plane with the two Control Planes as if they are > > to be treated in the same manner. I thought this short ID > > could serve as educator/reminder of sorts to reduce this > > occurrence in the future. > >we can discuss and write spec on *which* QoS mechanism can be >used. But, not *if* QoS mechanism should be employed. Their is >no study to prove that QoS/provisioning is better than the >other. We can keep debating on either side of the fence. > >Their are strong arguments on why QoS is not necessary and >why it is necessary for whatever reason. So, > > > >Do you mean to say, " Since the draft has classified > > >the application level stuff used for ieprep, one can infer whether > > >those application require QoS mechanisms based on their known > > >delay/jitter requirements." > > > > > > There is at least one more document I want to write as the > > next logical step of this document - which will hopefully > > target your comment quoted just above more directly. > >the follow-up draft can provide us guidelines based on both the >scenarios: > >- If I use best-effort, what are the things to be done for >creating an end to end ieprep service. Three of Kimberly's >mail regarding scenarios and one of rogan's mail >on data center will serve as a major input. > >- If I use QoS models, what are the things to be done for >creating an end to end ieprep service. An obvious approach >will be mapping your application level classification with >Fred's ieprep-packet-marking-policy. But, some text have to >be added for explaining inter-domain signaling methods. > >- It should also mention about various ieprep services that >may be helpful for emergency responders. For example, effective >use of systems like IAA ( Ran's mail.) > > > >My understanding of application-level signaling is that it helps in > > >differentiating various applications. The quality of service part > ^^^^^^^^^^^^^^^^^^^^^^^ > > >(network level) will remain the same whether we are going to use > > >in-band or out-of-band /receiver-initiated or source-initiated > > >signaling. > > > > Taking your statement at face value, I *could* read into it that (for > > example) SIP signaling is to have the same treatment (if > > there is any in the first place) as RTP. > >I did not mean that way. I meant *quality of service component* (like >Diffserv) rather than the actual quality measure (like delay/jitter.)in >the above quoted text. If you take the quality measure, it differs >depending on the application requirements. > > > > I think few would actually agree with this as a general rule. > >I can even argue the other way round. what if I give high-priority >to the scavenger traffic(if its my own intranet.) So, they are more >of policy issues. > > > RTP has delay/jitter tolerances that are far more sensitive to that > > Protocol's normal operation than does SIP or MGCP or MEGACO/H.248 > > messages. > > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Jan 24 19:34:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06358 for ; Fri, 24 Jan 2003 19:34:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P0rR508994 for ieprep-archive@odin.ietf.org; Fri, 24 Jan 2003 19:53:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0rRJ08991 for ; Fri, 24 Jan 2003 19:53:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06352 for ; Fri, 24 Jan 2003 19:33:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0q2J08960; Fri, 24 Jan 2003 19:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P0prJ08945 for ; Fri, 24 Jan 2003 19:51:53 -0500 Received: from kc-msxproto4.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06320 for ; Fri, 24 Jan 2003 19:32:09 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.111] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 18:35:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 Jan 2003 18:35:36 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02CF37@KC-MAIL4.kc.umkc.edu> Thread-Topic: polk-ieprep-flow-model-considerations-00 Thread-Index: AcLECAOSaCut7NAyQiS/YjRvUbHWFgAAB1eg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "James M. Polk" , X-OriginalArrivalTime: 25 Jan 2003 00:35:37.0062 (UTC) FILETIME=[ADDF0860:01C2C409] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0P0prJ08946 Subject: [Ieprep] RE: polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > For this ID, you aren't uncomfortable with the phrase "...if > (and which) QoS mechanisms..." What would you prefer for > this part of the text: > > #2 - "...which QoS mechanisms..." I vote for this. and an added clarification which includes your previous comments: > there have been discussions that have merged all combinations > of Data Plane with the two Control Planes as if they are > to be treated in the same manner. I thought this short ID > could serve as educator/reminder of sorts to reduce this > occurrence in the future. ....... > Since the draft has classified the application level stuff > used for ieprep, one can infer whether those application require > QoS mechanisms based on their known delay/jitter requirements. or just a reference to your draft-to-be-written. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 25 11:46:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25728 for ; Sat, 25 Jan 2003 11:46:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PH5gc30120 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 12:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PH5gJ30117 for ; Sat, 25 Jan 2003 12:05:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25720 for ; Sat, 25 Jan 2003 11:45:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PH0iJ29966; Sat, 25 Jan 2003 12:00:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PGvKJ29869 for ; Sat, 25 Jan 2003 11:57:20 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25686 for ; Sat, 25 Jan 2003 11:37:15 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Sat, 25 Jan 2003 11:39:53 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003012511403505177 for ; Sat, 25 Jan 2003 11:40:35 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Sat, 25 Jan 2003 11:40:20 -0500 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Date: Sat, 25 Jan 2003 11:40:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , http://www.washingtonpost.com/wp-dyn/articles/A41673-2003Jan25.html "The attack sought to take advantage of a software flaw discovered by researchers in July 2002 that permits hackers to seize control of corporate database servers. Microsoft deemed the problem "critical" and offered a free repairing patch, but it was impossible to know how many computer administrators applied the fix. "People need to do a better job about fixing vulnerabilities," Schmidt said. " _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 25 12:00:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25817 for ; Sat, 25 Jan 2003 12:00:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PHKJp31194 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 12:20:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHKJJ31191 for ; Sat, 25 Jan 2003 12:20:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25811 for ; Sat, 25 Jan 2003 12:00:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHJ2J31119; Sat, 25 Jan 2003 12:19:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHE8J30982 for ; Sat, 25 Jan 2003 12:14:08 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25769 for ; Sat, 25 Jan 2003 11:54:02 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id h0PGouj25538; Sat, 25 Jan 2003 08:50:56 -0800 (PST) Date: Sat, 25 Jan 2003 08:50:56 -0800 (PST) From: Bill Woodcock To: "King, Kimberly S." cc: "'ieprep@ietf.org'" Subject: Re: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > "The attack sought to take advantage of a software flaw > discovered by researchers in July 2002 that permits hackers > to seize control of corporate database servers. ^^^^^^^^^^^^^^^^^^ They misspelled "Microsoft SQL". Real servers were fine, of course. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 25 12:27:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26158 for ; Sat, 25 Jan 2003 12:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PHlUJ32736 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 12:47:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHlUJ32733 for ; Sat, 25 Jan 2003 12:47:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26153 for ; Sat, 25 Jan 2003 12:27:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHh7J32471; Sat, 25 Jan 2003 12:43:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PHObJ31291 for ; Sat, 25 Jan 2003 12:24:37 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25876 for ; Sat, 25 Jan 2003 12:04:31 -0500 (EST) Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 25 Jan 2003 09:08:14 -0800 Received: from BGREENEXP1 (dhcp-10-24-19-68.cisco.com [10.24.19.68]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA25370; Sat, 25 Jan 2003 09:08:00 -0800 (PST) Reply-To: From: "Barry Raveendran Greene" To: "'King, Kimberly S.'" , Subject: RE: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic Date: Sat, 25 Jan 2003 09:07:05 -0800 Organization: Cisco Systems Message-ID: <008d01c2c494$2fe6bd50$4413180a@cisco.com> 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, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What isn't being said is that inter-ISP Security communication systems worked and this worm was roughly contained within hours of the discovery. We're currently in the phase of more tightly containing the infected servers. > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of King, > Kimberly S. > Sent: Saturday, January 25, 2003 8:41 AM > To: 'ieprep@ietf.org' > Subject: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic > > http://www.washingtonpost.com/wp-dyn/articles/A41673-2003Jan25.html > > > "The attack sought to take advantage of a software flaw discovered by > researchers in July 2002 that permits hackers to seize control of corporate > database servers. Microsoft deemed the problem "critical" and offered a free > repairing patch, but it was impossible to know how many computer > administrators applied the fix. > > "People need to do a better job about fixing vulnerabilities," Schmidt said. > " > _______________________________________________ > 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 mailnull@www1.ietf.org Sat Jan 25 13:19:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26607 for ; Sat, 25 Jan 2003 13:19:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PId7X02832 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 13:39:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PId7J02829 for ; Sat, 25 Jan 2003 13:39:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26601 for ; Sat, 25 Jan 2003 13:18:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIbJJ02521; Sat, 25 Jan 2003 13:37:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIROJ01860 for ; Sat, 25 Jan 2003 13:27:24 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26454 for ; Sat, 25 Jan 2003 13:07:17 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.111] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Sat, 25 Jan 2003 11:44:35 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 25 Jan 2003 11:44:11 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02CF3F@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic Thread-Index: AcLElugZIoZoqeInRH6lGBgQ9CKw+wAAWxrA From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: , "King, Kimberly S." , X-OriginalArrivalTime: 25 Jan 2003 17:44:35.0152 (UTC) FILETIME=[6CA3F500:01C2C499] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0PIROJ01861 Subject: [Ieprep] RE: [I prep] FYI: Virus-Like Infection Slows Internet Traffic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > What isn't being said is that inter-ISP Security > communication systems worked and just curious. You mean uRPF, Black Hole Filtering and Sink Holes, which was discussed before? > this worm was roughly contained within hours of the > discovery. We're currently in the phase of more > tightly containing the infected servers. which helped better? the inundating Microsoft's security patches or the techniques which this list discussed last month ( egress/ingress filtering etc.. ftp://ftp-eng.cisco.com/cons/isp/security/ ) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 25 13:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26809 for ; Sat, 25 Jan 2003 13:36:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PIuTa03403 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 13:56:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIuTJ03400 for ; Sat, 25 Jan 2003 13:56:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26805 for ; Sat, 25 Jan 2003 13:36:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIq4J03297; Sat, 25 Jan 2003 13:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIntJ03226 for ; Sat, 25 Jan 2003 13:49:55 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26725 for ; Sat, 25 Jan 2003 13:29:47 -0500 (EST) Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 25 Jan 2003 10:33:32 -0800 Received: from BGREENEXP1 (dhcp-10-24-19-68.cisco.com [10.24.19.68]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA23045; Sat, 25 Jan 2003 10:33:16 -0800 (PST) Reply-To: From: "Barry Raveendran Greene" To: "'Ayyasamy, Senthilkumar \(UMKC-Student\)'" , "'King, Kimberly S.'" , Date: Sat, 25 Jan 2003 10:32:21 -0800 Organization: Cisco Systems Message-ID: <00a201c2c4a0$19466350$4413180a@cisco.com> 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, Build 10.0.4510 In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02CF3F@KC-MAIL4.kc.umkc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ieprep] RE: [I prep] FYI: Virus-Like Infection Slows Internet Traffic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No. I'm taking about people E-mailing (via the closed nsp-sec operational security alias) and talking to each other (combination of regular phone and iNOC-DBA phones). This problem is not fixed - it is contained. ACLs stopping all UDP traffic to port 1434. The key thing is that ISPs were talking to each other and applying the block even before they were seriously infected. So the spread of the worm was mitigated by good old inter-ISP communication. > -----Original Message----- > From: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:saq66@umkc.edu] > Sent: Saturday, January 25, 2003 9:44 AM > To: bgreene@cisco.com; King, Kimberly S.; ieprep@ietf.org > Subject: RE: [I prep] FYI: Virus-Like Infection Slows Internet Traffic > > > > What isn't being said is that inter-ISP Security > > communication systems worked and > > just curious. You mean uRPF, Black Hole Filtering > and Sink Holes, which was discussed before? > > > this worm was roughly contained within hours of the > > discovery. We're currently in the phase of more > > tightly containing the infected servers. > > which helped better? the inundating Microsoft's > security patches or the techniques which this list discussed > last month ( egress/ingress filtering etc.. > ftp://ftp-eng.cisco.com/cons/isp/security/ ) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sat Jan 25 14:17:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27233 for ; Sat, 25 Jan 2003 14:17:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0PJbX005622 for ieprep-archive@odin.ietf.org; Sat, 25 Jan 2003 14:37:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PJbXJ05619 for ; Sat, 25 Jan 2003 14:37:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27220 for ; Sat, 25 Jan 2003 14:17:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PJX6J04882; Sat, 25 Jan 2003 14:33:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PJUtJ04820 for ; Sat, 25 Jan 2003 14:30:55 -0500 Received: from paixhost.pch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27188 for ; Sat, 25 Jan 2003 14:10:48 -0500 (EST) Received: from ns1.pch.net (ns1.pch.net [206.220.231.1]) by paixhost.pch.net (8.11.6/8.11.6) with ESMTP id h0PJ7aj27147; Sat, 25 Jan 2003 11:07:36 -0800 (PST) Date: Sat, 25 Jan 2003 11:07:36 -0800 (PST) From: Bill Woodcock To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: bgreene@cisco.com, "King, Kimberly S." , Subject: Re: [Ieprep] RE: [I prep] FYI: Virus-Like Infection Slows Internet Traffic In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02CF3F@KC-MAIL4.kc.umkc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > > What isn't being said is that inter-ISP Security > > communication systems worked and > just curious. You mean uRPF, Black Hole Filtering > and Sink Holes, which was discussed before? No, those are means of response. The _inter-ISP security communications systems_ worked. That is, ISPs were able to effectively and efficiently communicate with each other regarding the diagnosis and solution to the problem. > > this worm was roughly contained within hours of the > > discovery. > which helped better? the inundating Microsoft's > security patches or the techniques which this list discussed > last month ( egress/ingress filtering etc.. The patch is of no use, since in order for it to do anything, individual offending hosts have to be tracked down, customers found, customers woken up, customers convinced that this really is their problem, patches conveyed to customers, customers drive to colo site, customers sit around twiddling with their box for some hours. In other words, many months. Packet filtering contained the problem quickly, on the other hand. -Bill _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Sun Jan 26 16:02:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21917 for ; Sun, 26 Jan 2003 16:02:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QLMEh24457 for ieprep-archive@odin.ietf.org; Sun, 26 Jan 2003 16:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QLMEJ24454 for ; Sun, 26 Jan 2003 16:22:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21911 for ; Sun, 26 Jan 2003 16:01:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QLKMJ24371; Sun, 26 Jan 2003 16:20:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QLJZJ24291 for ; Sun, 26 Jan 2003 16:19:35 -0500 Received: from halt-in.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21774 for ; Sun, 26 Jan 2003 15:58:56 -0500 (EST) Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 26 Jan 2003 13:02:22 -0800 Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA13009; Sun, 26 Jan 2003 13:02:24 -0800 (PST) Message-Id: <4.3.2.7.2.20030126150026.02053e98@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 26 Jan 2003 15:02:21 -0600 To: "Ayyasamy, Senthilkumar (UMKC-Student)" , From: "James M. Polk" In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02CF37@KC-MAIL4.kc.umkc.ed u> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] RE: polk-ieprep-flow-model-considerations-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Thanks for the input - I will capture this in the next version At 06:35 PM 1/24/2003 -0600, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > For this ID, you aren't uncomfortable with the phrase "...if > > (and which) QoS mechanisms..." What would you prefer for > > this part of the text: > > > > #2 - "...which QoS mechanisms..." > >I vote for this. > >and an added clarification which includes your previous comments: > > > there have been discussions that have merged all combinations > > of Data Plane with the two Control Planes as if they are > > to be treated in the same manner. I thought this short ID > > could serve as educator/reminder of sorts to reduce this > > occurrence in the future. > ....... > > Since the draft has classified the application level stuff > > used for ieprep, one can infer whether those application require > > QoS mechanisms based on their known delay/jitter requirements. > or just a reference to your draft-to-be-written. cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Jan 27 15:03:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24812 for ; Mon, 27 Jan 2003 15:03:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RKNfT14376 for ieprep-archive@odin.ietf.org; Mon, 27 Jan 2003 15:23:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKNeJ14373 for ; Mon, 27 Jan 2003 15:23:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24802 for ; Mon, 27 Jan 2003 15:02:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKM9J14303; Mon, 27 Jan 2003 15:22:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKLgJ14284 for ; Mon, 27 Jan 2003 15:21:42 -0500 Received: from [209.22.88.17] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24743 for ; Mon, 27 Jan 2003 15:00:36 -0500 (EST) Received: from mtassp3.ncr.disa.mil by [209.22.88.17] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 27 Jan 2003 19:54:51 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 15:03:38 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4CCD@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'bgreene@cisco.com'" , "'King, Kimberly S.'" , ieprep@ietf.org Subject: RE: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic Date: Mon, 27 Jan 2003 15:03:26 -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-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , More info on ... MS-SQL Server Worm (also called Sapphire, SQL Slammer, SQL Hell) A SPECIAL REPORT FROM THE SANS RESEARCH OFFICE A worm launched Saturday morning January 25, about 12:30 AM (EST), takes advantage of a buffer overflow vulnerability in Microsoft SQL Server 2000. The SQL vulnerability was initially reported in July of 2002. The worm is also being called Sapphire, SQL Slammer, and SQL Hell. Microsoft reports that the worm also infects MSDE 2000 systems, typically used by software developers. The worm attempts to infect systems at (approximately) randomly generated IP addresses. The worm has no back doors or code for flooding like other worms (Code Red). However, by using UDP packets for infection, the worm allows infected machines to generate huge amounts of traffic; even greater than that produced by most code written specifically for flooding. Thus, in attempting to infect other systems, the worm has powerful denial of service capabilities. The worm resides in memory, and not on disk, so it can be eliminated using a system reboot. However, if the defensive perimeter is not upgraded to block offending udp packets or the system is not patched, it will be quickly reinfected. The worm uses UDP port 1434, so the impact of the worm can be reduced by blocking inbound and outbound traffic destined for UDP port 1434. Sites should use caution when blocking all traffic to this port, since it is legitimately used by Microsoft SQL services. Some sites have reported high levels of UDP traffic to port 1433 as well. A CERT Advisory said the worm has caused various levels of network degradation across the Internet. One news story reported that ATMs of Bank of America were impacted by the worm. According to the various reports, about 35,000 hosts had been infected as of Saturday. Incidents.Org reports 120,000 IP addresses infected by Sunday at 10 AM (EST). Incidents.org preliminary analysis of worm (includes a packet trace): http://isc.incidents.org/analysis.html?id=180 Original Vulnerability Analysis by David Litchfield: http://www.nextgenss.com/advisories/mssql-udp.txt CERT Advisory: http://www.cert.org/advisories/CA-2003-04.html Microsoft Advisory: http://www.microsoft.com/security/slammer.asp Cisco Security Notice (Recommendations): http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml Cisco Security Advisory: http://www.cisco.com/warp/public/707/cisco-sa-20030126-ms02-061.shtml Microsoft Security Bulletin (originally posted July 24, 2002): http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ bulletin/MS02-039.asp -----Original Message----- From: Barry Raveendran Greene [mailto:bgreene@cisco.com] Sent: Saturday, January 25, 2003 12:07 PM To: 'King, Kimberly S.'; ieprep@ietf.org Subject: RE: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic What isn't being said is that inter-ISP Security communication systems worked and this worm was roughly contained within hours of the discovery. We're currently in the phase of more tightly containing the infected servers. > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of King, > Kimberly S. > Sent: Saturday, January 25, 2003 8:41 AM > To: 'ieprep@ietf.org' > Subject: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic > > http://www.washingtonpost.com/wp-dyn/articles/A41673-2003Jan25.html > > > "The attack sought to take advantage of a software flaw discovered by > researchers in July 2002 that permits hackers to seize control of corporate > database servers. Microsoft deemed the problem "critical" and offered a free > repairing patch, but it was impossible to know how many computer > administrators applied the fix. > > "People need to do a better job about fixing vulnerabilities," Schmidt said. > " > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Jan 27 15:15:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25242 for ; Mon, 27 Jan 2003 15:15:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RKZho14906 for ieprep-archive@odin.ietf.org; Mon, 27 Jan 2003 15:35:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKZhJ14903 for ; Mon, 27 Jan 2003 15:35:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25233 for ; Mon, 27 Jan 2003 15:14:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKY1J14800; Mon, 27 Jan 2003 15:34:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKWKJ14748 for ; Mon, 27 Jan 2003 15:32:20 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25189 for ; Mon, 27 Jan 2003 15:11:13 -0500 (EST) Received: from [63.105.122.235] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1584921; Mon, 27 Jan 2003 15:14:42 -0500 Date: Mon, 27 Jan 2003 15:14:41 -0500 Subject: Re: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'bgreene@cisco.com'" , "'King, Kimberly S.'" , ieprep@ietf.org To: "Nguyen, An" From: Marshall Eubanks In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4CCD@emshqs1.ncr.disa.mil> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As has been discussed extensively on NANOG and elsewhere http://biz.yahoo.com/rb/030125/tech_virus_boa_1.html Reuters Bank of America ATMs Disrupted by Virus Saturday January 25, 5:33 pm ET SEATTLE (Reuters) - Bank of America Corp. (NYSE:BAC - News) said on Saturday that customers at a majority of its 13,000 automatic teller machines were unable to process customer transactions after a malicious computer worm nearly froze Internet traffic worldwide. Bank of America spokeswoman Lisa Gagnon said by phone from the company's headquarters in Charlotte, North Carolina, that many, if not a majority of the No. 3 U.S. bank's ATMs were back online and that their automated banking network would recover by late Saturday. "We have been impacted, and for a while customers could not use ATMs and customer services could not access customer information," Gagnon said. Regards Marshall Eubanks On Monday, January 27, 2003, at 03:03 PM, Nguyen, An wrote: > More info on ... > > MS-SQL Server Worm (also called Sapphire, SQL Slammer, SQL Hell) > > A SPECIAL REPORT FROM THE SANS RESEARCH OFFICE > > A worm launched Saturday morning January 25, about 12:30 AM (EST), > takes advantage of a buffer overflow vulnerability in Microsoft SQL > Server 2000. The SQL vulnerability was initially reported in July > of 2002. The worm is also being called Sapphire, SQL Slammer, and > SQL Hell. > > Microsoft reports that the worm also infects MSDE 2000 systems, > typically used by software developers. > > The worm attempts to infect systems at (approximately) randomly > generated IP addresses. The worm has no back doors or code for > flooding like other worms (Code Red). However, by using UDP packets > for infection, the worm allows infected machines to generate huge > amounts of traffic; even greater than that produced by most code > written specifically for flooding. Thus, in attempting to infect > other systems, the worm has powerful denial of service capabilities. > > The worm resides in memory, and not on disk, so it can be eliminated > using a system reboot. However, if the defensive perimeter is not > upgraded to block offending udp packets or the system is not patched, > it will be quickly reinfected. > > The worm uses UDP port 1434, so the impact of the worm can be > reduced by blocking inbound and outbound traffic destined for UDP > port 1434. Sites should use caution when blocking all traffic to this > port, since it is legitimately used by Microsoft SQL services. Some > sites have reported high levels of UDP traffic to port 1433 as well. > > A CERT Advisory said the worm has caused various levels of network > degradation across the Internet. One news story reported that > ATMs of Bank of America were impacted by the worm. According to the > various reports, about 35,000 hosts had been infected as of Saturday. > Incidents.Org reports 120,000 IP addresses infected by Sunday at 10 AM > (EST). > > Incidents.org preliminary analysis of worm (includes a packet trace): > http://isc.incidents.org/analysis.html?id=180 > > Original Vulnerability Analysis by David Litchfield: > http://www.nextgenss.com/advisories/mssql-udp.txt > > CERT Advisory: > http://www.cert.org/advisories/CA-2003-04.html > > Microsoft Advisory: > http://www.microsoft.com/security/slammer.asp > > Cisco Security Notice (Recommendations): > http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml > > Cisco Security Advisory: > http://www.cisco.com/warp/public/707/cisco-sa-20030126-ms02-061.shtml > > Microsoft Security Bulletin (originally posted July 24, 2002): > http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ > bulletin/MS02-039.asp > > > -----Original Message----- > From: Barry Raveendran Greene [mailto:bgreene@cisco.com] > Sent: Saturday, January 25, 2003 12:07 PM > To: 'King, Kimberly S.'; ieprep@ietf.org > Subject: RE: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic > > > > What isn't being said is that inter-ISP Security communication systems > worked > and this worm was roughly contained within hours of the discovery. We're > currently in the phase of more tightly containing the infected servers. > >> -----Original Message----- >> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of > King, >> Kimberly S. >> Sent: Saturday, January 25, 2003 8:41 AM >> To: 'ieprep@ietf.org' >> Subject: [Ieprep] FYI: Virus-Like Infection Slows Internet Traffic >> >> http://www.washingtonpost.com/wp-dyn/articles/A41673-2003Jan25.html >> >> >> "The attack sought to take advantage of a software flaw discovered by >> researchers in July 2002 that permits hackers to seize control of > corporate >> database servers. Microsoft deemed the problem "critical" and offered a > free >> repairing patch, but it was impossible to know how many computer >> administrators applied the fix. >> >> "People need to do a better job about fixing vulnerabilities," Schmidt > said. >> " >> _______________________________________________ >> 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 > 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 mailnull@www1.ietf.org Fri Jan 31 21:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24983 for ; Fri, 31 Jan 2003 21:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h112ElW01894 for ieprep-archive@odin.ietf.org; Fri, 31 Jan 2003 21:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h112ElJ01891 for ; Fri, 31 Jan 2003 21:14:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24967 for ; Fri, 31 Jan 2003 21:10:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h112DKJ01836; Fri, 31 Jan 2003 21:13:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h112CIJ01813 for ; Fri, 31 Jan 2003 21:12:18 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24945 for ; Fri, 31 Jan 2003 21:08:02 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.111] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 31 Jan 2003 20:11:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 31 Jan 2003 20:11:34 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02CF6C@KC-MAIL4.kc.umkc.edu> Thread-Topic: The Spread of the Sapphire/Slammer SQL Worm Thread-Index: AcLJjySuWFLgHUO9RKqO8N9Aki8J8gAB5iLg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: X-OriginalArrivalTime: 01 Feb 2003 02:11:35.0214 (UTC) FILETIME=[3EE38CE0:01C2C997] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h112CIJ01814 Subject: [Ieprep] FW: The Spread of the Sapphire/Slammer SQL Worm Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit -----Original Message----- From: vern@ee.lbl.gov [mailto:vern@ee.lbl.gov] Sent: Friday, January 31, 2003 7:13 PM To: nanog@merit.edu Subject: The Spread of the Sapphire/Slammer SQL Worm We have completed our preliminary analysis of the spread of the Sapphire/Slammer SQL worm. This worm required roughly 10 minutes to spread worldwide making it by far the fastest worm to date. In the early stages the worm was doubling in size every 8.5 seconds. At its peak, achieved approximately 3 minutes after it was released, Sapphire scanned the net at over 55 million IP addresses per second. It infected at least 75,000 victims and probably considerably more. This remarkable speed, nearly two orders of magnitude faster than Code Red, was the result of a bandwidth-limited scanner. Since Sapphire didn't need to wait for responses, each copy could scan at the maximum rate that the processor and network bandwidth could support. There were also two noteworthy bugs in the pseudo-random number generator which complicated our analysis and limited our ability to estimate the total infection but did not slow the spread of the worm. The full analysis is available at http://www.caida.org/analysis/security/sapphire/ http://www.silicondefense.com/sapphire/ http://www.cs.berkeley.edu/~nweaver/sapphire/ David Moore, CAIDA & UCSD CSE Vern Paxson, ICIR & LBNL Stefan Savage, UCSD CSE Colleen Shannon, CAIDA Stuart Staniford, Silicon Defense Nicholas Weaver, Silicon Defense and UC Berkeley EECS _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep