From mailman-owner@ietf.org Sat Jun 1 07:00:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18774 for ; Sat, 1 Jun 2002 07:00:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09332 for ; Sat, 1 Jun 2002 07:01:01 -0400 (EDT) Date: Sat, 1 Jun 2002 07:01:01 -0400 (EDT) Message-Id: <200206011101.HAA09332@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ieprep-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ieprep-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-web-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org fPSM https://www1.ietf.org/mailman/options/ieprep/ieprep-web-archive@ietf.org From ieprep-admin@ietf.org Mon Jun 3 02:40:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04795 for ; Mon, 3 Jun 2002 02:40:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20181; Mon, 3 Jun 2002 02:36:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20149 for ; Mon, 3 Jun 2002 02:36:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04748; Mon, 3 Jun 2002 02:35:51 -0400 (EDT) Received: from FRED-W2K6.cisco.com (ams-clip-vpn-dhcp4245.cisco.com [10.50.16.148]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g536ZePJ025743; Sun, 2 Jun 2002 23:35:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20020603073419.023d2a38@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Jun 2002 07:35:38 +0100 To: minutes@ietf.org From: Fred Baker Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Minutes of May Interim Meeting Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org You may find the minutes for the meeting, plus the powerpoint presentations presented, at ftp://ftpeng.cisco.com/fred/ieprep-may. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 3 03:18:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05244 for ; Mon, 3 Jun 2002 03:18:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22195; Mon, 3 Jun 2002 03:17:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22157 for ; Mon, 3 Jun 2002 03:17:44 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05223 for ; Mon, 3 Jun 2002 03:17:14 -0400 (EDT) Received: from FRED-W2K6.cisco.com (ams-clip-vpn-dhcp4245.cisco.com [10.50.16.148]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g537GePJ007564; Mon, 3 Jun 2002 00:16:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20020603081324.048b8170@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Jun 2002 08:16:38 +0100 To: Sean Donelan From: Fred Baker Subject: RE: [Ieprep] MLPP Requirements Cc: ieprep@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Thanks for including the way a Cisco Router configures the capabilities in IP that were obsoleted by RFC 1122 in 1989. A more up to date configuration example might have been as described in ftp://ftpeng.cisco.com/fred/ieprep/canonical_diffserv_configuration.txt. One of my big concerns in this discussion is the amount of outdated information rattling around in it... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 3 03:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05259 for ; Mon, 3 Jun 2002 03:18:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22031; Mon, 3 Jun 2002 03:12:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21995 for ; Mon, 3 Jun 2002 03:12:51 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05180 for ; Mon, 3 Jun 2002 03:12:21 -0400 (EDT) Received: from FRED-W2K6.cisco.com (ams-clip-vpn-dhcp4245.cisco.com [10.50.16.148]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g537CFPJ006030; Mon, 3 Jun 2002 00:12:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20020603081141.048821d8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Jun 2002 08:12:13 +0100 To: Ken Carlberg From: Fred Baker Subject: Re: [Ieprep] MLPP Requirements Cc: ieprep In-Reply-To: <1590.1022600247@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:37 AM 5/29/2002 +0100, Ken Carlberg wrote: >however, imo your request may be helped if you focus on requirements >for supporting MLPP (an ITU standard), as opposed to the requirements >of a single organization. Or, is it your opinion that DoD requirements >with respect to MLPP are different than that which one would associate >with the ITU I.225.3 standard? Could you make a copy of ITU I.225.3 openly available so we can discuss it? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jun 6 12:41:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19888 for ; Thu, 6 Jun 2002 12:41:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16538; Thu, 6 Jun 2002 12:39:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16507 for ; Thu, 6 Jun 2002 12:39:56 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19844 for ; Thu, 6 Jun 2002 12:39:26 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 12:39:55 -0400 Message-ID: From: "Folts, Harold" To: "'ieprep@ietf.org'" Date: Thu, 6 Jun 2002 12:39:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D78.C6E15D10" Subject: [Ieprep] Requirements Presentation Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D78.C6E15D10 Content-Type: text/plain I have posted on my FTS site a copy of my requirements presentation given at the interim ieprep meeting on 20 May. Sorry for the delay in making this available. ftp://iepscheme.net/pub/ieps/docs/ ------_=_NextPart_001_01C20D78.C6E15D10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Requirements Presentation

I have posted on my FTS site a copy of = my requirements presentation given at the interim ieprep meeting on 20 = May.

Sorry for the delay in making this = available.

ftp://iepscheme.net/pub/ieps/docs/

------_=_NextPart_001_01C20D78.C6E15D10-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 08:49:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25910 for ; Wed, 12 Jun 2002 08:49:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25304; Wed, 12 Jun 2002 08:50:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25278 for ; Wed, 12 Jun 2002 08:50:00 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25878 for ; Wed, 12 Jun 2002 08:49:23 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 08:48:58 -0400 Message-ID: From: "Berg, Dennis" To: "'James M. Polk'" Cc: ieprep@ietf.org Date: Wed, 12 Jun 2002 08:48:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] Multiple namespaces for resource_priority Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org James, As I was drafting comments to the Resource-Priority Header ID, I realized that I am not clear on the issue of multiple namespaces. Specifically, how will multiple namespaces be harmonized, or will it be necessary to have only one namespace operative in a given network? A similar issue is arising right now in the NCS's Industry Requirements development for the extension of GETS to wireless (called WPS - Wireless Priority Service). The proposal is on the table to use the optional MLPP Precedence field in the ISUP IAM to pass the WPS priority levels through the landline network. The issue is whether there will be interoperability conflicts in such a use with any networks that may have implemented a service using MLPP, even if the service is via a Private Virtual Network. Similarly, in the wireless networks, where eMLPP functionality is being adapted for WPS, there is an interoperability issue around preemption. Apparently, when executing preemption, the system can consider all calls from all eMLPP subscribers as candidates for preemption. The way around this seems to be that each subscriber has a parameter for "capable-capable" and "non-preemptible". This may allow two services to coexist in the same network, but only if one service does not want any preemption as part of the service. The list has had some discussion of using a "public network" or "public network-{country}" namespace and distinguishing this from namespaces that are intended for use in private IP networks. I suppose that could work, but the criterion for "public network" is unclear. If a traditional circuit-switched "long distance" network migrates to an IP transport, then that's a case of a public network? As long as services are "sold" on the network, it is public? Does "public" require governance by some Government jurisdiction? So how could this be applied to the Internet? Concerning ownership and control of namespaces, the AINSI standard that specifies the HPC Codepoint (used for GETS) for the IAM Calling Party Category states that the Office of the Manager, National Communication System drove the standard. In our subcontracts with the vendors to develop the HPC capability, DynCorp, as a subcontractor to the OMNCS, has required the vendors to include a statement in their documentation that the functionality is under the control of the OMNCS and that it may not be utilized without their coordination and consent. We will be including a similar restriction in the subcontracts with vendors for the WPS functionality in wireless products. Will send you a marked-up version of the resource priority document shortly. Dennis Berg GETS & WPS Integration Contractor, Deputy Program Manager, Engineering DynCorp IS 703-818-4608 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 09:13:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26836 for ; Wed, 12 Jun 2002 09:13:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27236; Wed, 12 Jun 2002 09:13:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27200 for ; Wed, 12 Jun 2002 09:13:06 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26772 for ; Wed, 12 Jun 2002 09:12:27 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jun 2002 14:12:56 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: schulzrinne@cs.columbia.edu Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 14:12:55 +0100 Message-ID: <963.1023887575@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] (no subject) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Henning, > Below are some requirements for such a mechanism: > > Not specific to one domain: The mechanism should not be specific > to one country or particular priority mechanism. For > example, there are currently at least four priority schemes > in widespread use: Q.735, with five levels, the U.S. > defense network and NATO with five levels, the United > States GETS (Government Emergency Telecommunications > Systems) scheme with implied higher priority and the > British GTPS system ???. the above may need a bit of clarification. I think one could argue that a specific NameSpace represents a "particular priority mechanism". I can gather that what you are saying is that the NameSpace should not reflect a specific organization or implementation. And you also want to avoid a one-to-one correlation between a namespace and geographic/geo- political boundaries. thats fine. one the other hand, I assume that NameSpace(s) that correlate to a standard like MLPP (from ITU) would be fine. valid interpretation? also, would it be fine to state that private or experimental NameSpace(s) could be defined, but they simply would not be registered with IANA. We kind of have that with the current diff-serv allocation of code points. The one difference with the diff-serv analogy is that I do NOT think there will be a need to additional parameter stating whether the NameSpace is public or private. if the NameSpace is not one listed by IANA, then by default its private. also, in page 3 you have the following... > Priority mechanisms can be roughly categorized by whether they use a > priority queue for resource attempts or whether they preempt existing > resource uses (e.g., calls). The choice between these mechanisms > depends on the operational needs and characteristics of the network, > e.g., on the number of active requests in the system and the fraction > of prioritized calls. Generally, if the number of prioritized calls > is small compared to the system capacity and the system capacity is > large, it is likely that another call will naturally terminate in > short order when a higher-priority call arrives. Thus, it is > conceivable that the system indication can sometimes cause > preemption, while otherwise it just ...it looks like the last sentence has been accidently chopped off. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 09:20:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27014 for ; Wed, 12 Jun 2002 09:20:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27627; Wed, 12 Jun 2002 09:19:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27593 for ; Wed, 12 Jun 2002 09:19:04 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26969 for ; Wed, 12 Jun 2002 09:18:27 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jun 2002 14:18:46 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org In-reply-to: Your message of "Wed, 12 Jun 2002 14:12:55 BST." <963.1023887575@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 14:18:44 +0100 Message-ID: <978.1023887924@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] draft-schulzrinne-ieprep-resource-req-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org sorry. my previous message was for Henning's Requirements for Resource Priority Mechanisms draft i forgot to add the draft name to the subject line -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 11:50:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02286 for ; Wed, 12 Jun 2002 11:50:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06595; Wed, 12 Jun 2002 11:45:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06559 for ; Wed, 12 Jun 2002 11:45:51 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02075 for ; Wed, 12 Jun 2002 11:45:15 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 11:44:50 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Ken Carlberg'" , schulzrinne@cs.columbia.edu Cc: ieprep@ietf.org Subject: RE: [Ieprep] Date: Wed, 12 Jun 2002 11:44:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ken, I have an earlier response from Henning that says: "Yes, just an incomplete sentence. Should read: Thus, it is conceivable that the priority indication can sometimes cause preemption, while otherwise it just influences whether requests are queued instead of discarded and what queueing policy is being applied." -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Wednesday, June 12, 2002 9:13 AM To: schulzrinne@cs.columbia.edu Cc: ieprep@ietf.org Subject: [Ieprep] (no subject) Henning, ... also, in page 3 you have the following... > Priority mechanisms can be roughly categorized by whether they use a > priority queue for resource attempts or whether they preempt existing > resource uses (e.g., calls). The choice between these mechanisms > depends on the operational needs and characteristics of the network, > e.g., on the number of active requests in the system and the fraction > of prioritized calls. Generally, if the number of prioritized calls > is small compared to the system capacity and the system capacity is > large, it is likely that another call will naturally terminate in > short order when a higher-priority call arrives. Thus, it is > conceivable that the system indication can sometimes cause > preemption, while otherwise it just ...it looks like the last sentence has been accidently chopped off. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 12:12:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03279 for ; Wed, 12 Jun 2002 12:12:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08926; Wed, 12 Jun 2002 12:11:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08894 for ; Wed, 12 Jun 2002 12:11:55 -0400 (EDT) Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03217 for ; Wed, 12 Jun 2002 12:11:20 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d01.mx.aol.com (mail_out_v32.5.) id i.111.13979496 (3940); Wed, 12 Jun 2002 12:11:11 -0400 (EDT) Message-ID: <111.13979496.2a38cc9f@aol.com> Date: Wed, 12 Jun 2002 12:11:11 EDT Subject: Re: [Ieprep] (no subject) To: K.Carlberg@cs.ucl.ac.uk, schulzrinne@cs.columbia.edu CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_111.13979496.2a38cc9f_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_111.13979496.2a38cc9f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 9:14:10 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > > Not specific to one domain: The mechanism should not be specific > > to one country or particular priority mechanism. For > > example, there are currently at least four priority schemes > > in widespread use: Q.735, with five levels, the U.S. > > defense network and NATO with five levels, the United > > States GETS (Government Emergency Telecommunications > > Systems) scheme with implied higher priority and the > > British GTPS system ???. > Just to clarifiy, the priority scheme in Q.735 is exactly the same as the US defense network. Mike Pierce --part1_111.13979496.2a38cc9f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 9:14:10 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes:


>        Not specific to one domain: The mechanism should not be specific
>             to one country or particular priority mechanism. For
>             example, there are currently at least four priority schemes
>             in widespread use: Q.735, with five levels, the U.S.
>             defense network and NATO with five levels, the United
>             States GETS (Government Emergency Telecommunications
>             Systems) scheme with implied higher priority and the
>             British GTPS system ???.


Just to clarifiy, the priority scheme in Q.735 is exactly the same as the US defense network.

Mike Pierce
--part1_111.13979496.2a38cc9f_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 12:23:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03575 for ; Wed, 12 Jun 2002 12:23:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09442; Wed, 12 Jun 2002 12:17:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09408 for ; Wed, 12 Jun 2002 12:17:38 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03411 for ; Wed, 12 Jun 2002 12:17:04 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 12:16:35 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Mpierce1@aol.com'" , K.Carlberg@cs.ucl.ac.uk, schulzrinne@cs.columbia.edu Cc: ieprep@ietf.org Subject: RE: [Ieprep] (no subject) Date: Wed, 12 Jun 2002 12:16:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Do you know where Q.735 is, or is planned to be, implemented? Is it on the PSTN, or on a "private" telecom network? Who (if anyone) would be the "owner" of the q735 namespace? -----Origi nal Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, June 12, 2002 12:11 PM To: K.Carlberg@cs.ucl.ac.uk; schulzrinne@cs.columbia.edu Cc: ieprep@ietf.org Subject: Re: [Ieprep] (no subject) In a message dated 6/12/02 9:14:10 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > Not specific to one domain: The mechanism should not be specific > to one country or particular priority mechanism. For > example, there are currently at least four priority schemes > in widespread use: Q.735, with five levels, the U.S. > defense network and NATO with five levels, the United > States GETS (Government Emergency Telecommunications > Systems) scheme with implied higher priority and the > British GTPS system ???. Just to clarifiy, the priority scheme in Q.735 is exactly the same as the US defense network. Mike Pierce _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 12 14:47:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08998 for ; Wed, 12 Jun 2002 14:47:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18320; Wed, 12 Jun 2002 14:44:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18286 for ; Wed, 12 Jun 2002 14:44:52 -0400 (EDT) Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08908 for ; Wed, 12 Jun 2002 14:44:16 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v32.5.) id r.36.28d43023 (3940); Wed, 12 Jun 2002 14:44:05 -0400 (EDT) Message-ID: <36.28d43023.2a38f075@aol.com> Date: Wed, 12 Jun 2002 14:44:05 EDT Subject: Re: [Ieprep] (no subject) To: Janet.Gunn@DynCorp.com, K.Carlberg@cs.ucl.ac.uk, schulzrinne@cs.columbia.edu CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_36.28d43023.2a38f075_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_36.28d43023.2a38f075_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 12:17:07 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: > Do you know where Q.735 is, or is planned to be, implemented? Is it on the > PSTN, or on a "private" telecom network? Who (if anyone) would be the > "owner" of the q735 namespace? > > I don't know of anyplace where Q.735 is used in a "public" network. But I'm sure it is implemented in switches that also provide public network service. It's intended use was clearly within a "private" telecom network, such as the Defense Switched Network. But remember that part of a "private" network may share physical resources with a "public" network. Your question on the proposed q735 namespace is one that I need to address to justify the creation of such a namespace. I know that I haven't done a complete job of this. First, no one needs to "own" the namespace. The intention is a very limited one - providing the interworking between two ISUP-based networks through a SIP-based part. Anyone could use it for this purpose. The intention was to allow the gateways to perfom a straightforward mapping, without any interpretation, of the values in the IAM to a similar one in the INVITE. (For example, the dsn namespace requires that the gateway understand the meaining of the character "FLASH" and convert it to a binary value 2.) Of course, as other discussions on ISUP-SIP mapping and encapsulation are showing, there may already be other ways to support this interworking scenario. The q735 namespace was essentially an extension to the ISUP to SIP mapping, with the idea that the mapping needed to include everything that might need interworking between ISUP and SIP. Perhaps it can be handled with pure encapsulation, if its relation with mapping can be better defined. Mike Pierce --part1_36.28d43023.2a38f075_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 12:17:07 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes:


Do you know where Q.735 is, or is planned to be, implemented?  Is it on the
PSTN, or on a "private" telecom network?  Who (if anyone) would be the
"owner" of the q735 namespace?



I don't know of anyplace where Q.735 is used in a "public" network. But I'm sure it is implemented in switches that also provide public network service. It's intended use was clearly within a "private" telecom network, such as the Defense Switched Network. But remember that part of a "private" network may share physical resources with a "public" network.

Your question on the proposed q735 namespace is one that I need to address to justify the creation of such a namespace. I know that I haven't done a complete  job of this.

First, no one needs to "own" the namespace. The intention is a very limited one - providing the interworking between two ISUP-based networks through a SIP-based part. Anyone could use it for this purpose. The intention was to allow the gateways to perfom a straightforward mapping, without any interpretation, of the values in the IAM to a similar one in the INVITE. (For example, the dsn namespace requires that the gateway understand the meaining of the character "FLASH" and convert it to a binary value 2.)

Of course, as other discussions on ISUP-SIP mapping and encapsulation are showing, there may already be other ways to support this interworking scenario. The q735 namespace was essentially an extension to the ISUP to SIP mapping, with the idea that the mapping needed to include everything that might need interworking between ISUP and SIP. Perhaps it can be handled with pure encapsulation, if its relation with mapping can be better defined.

Mike Pierce
--part1_36.28d43023.2a38f075_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 14 14:03:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08306 for ; Fri, 14 Jun 2002 14:03:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27722; Fri, 14 Jun 2002 14:01:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27691 for ; Fri, 14 Jun 2002 14:01:33 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08247 for ; Fri, 14 Jun 2002 14:00:56 -0400 (EDT) Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5EI1Vxc009192; Fri, 14 Jun 2002 14:01:32 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g5EI1Sv02832; Fri, 14 Jun 2002 14:01:29 -0400 Message-ID: <3D0A2F55.5060100@cs.columbia.edu> Date: Fri, 14 Jun 2002 14:00:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Berg, Dennis" CC: "'James M. Polk'" , ieprep@ietf.org Subject: Re: [Ieprep] Multiple namespaces for resource_priority References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Thanks for your comment. A quick (non)reply: This is policy outside the protocol. If a gateway supports two orderings A and B (here, represented by namespaces), they are apples and oranges. It's up the operator to decide how many oranges are equivalent to an apple. (In reality, the operator is likely to have to discuss this choice with its customers, particularly the ones drawing the shorter straw.) I don't think any IETF spec can say how a particular namespace relates to any other namespace. All we have is a partial ordering, not a total ordering. Berg, Dennis wrote: > James, > > As I was drafting comments to the Resource-Priority Header ID, I realized > that I am not clear on the issue of multiple namespaces. Specifically, how > will multiple namespaces be harmonized, or will it be necessary to have only > one namespace operative in a given network? > > A similar issue is arising right now in the NCS's Industry Requirements > development for the extension of GETS to wireless (called WPS - Wireless > Priority Service). The proposal is on the table to use the optional MLPP > Precedence field in the ISUP IAM to pass the WPS priority levels through the > landline network. The issue is whether there will be interoperability > conflicts in such a use with any networks that may have implemented a > service using MLPP, even if the service is via a Private Virtual Network. > Similarly, in the wireless networks, where eMLPP functionality is being > adapted for WPS, there is an interoperability issue around preemption. > Apparently, when executing preemption, the system can consider all calls > from all eMLPP subscribers as candidates for preemption. The way around > this seems to be that each subscriber has a parameter for "capable-capable" > and "non-preemptible". This may allow two services to coexist in the same > network, but only if one service does not want any preemption as part of the > service. > > The list has had some discussion of using a "public network" or "public > network-{country}" namespace and distinguishing this from namespaces that > are intended for use in private IP networks. I suppose that could work, but > the criterion for "public network" is unclear. If a traditional > circuit-switched "long distance" network migrates to an IP transport, then > that's a case of a public network? As long as services are "sold" on the > network, it is public? Does "public" require governance by some Government > jurisdiction? So how could this be applied to the Internet? > > Concerning ownership and control of namespaces, the AINSI standard that > specifies the HPC Codepoint (used for GETS) for the IAM Calling Party > Category states that the Office of the Manager, National Communication > System drove the standard. In our subcontracts with the vendors to develop > the HPC capability, DynCorp, as a subcontractor to the OMNCS, has required > the vendors to include a statement in their documentation that the > functionality is under the control of the OMNCS and that it may not be > utilized without their coordination and consent. We will be including a > similar restriction in the subcontracts with vendors for the WPS > functionality in wireless products. > > Will send you a marked-up version of the resource priority document shortly. > > Dennis Berg > GETS & WPS Integration Contractor, Deputy Program Manager, Engineering > DynCorp IS > 703-818-4608 > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jun 16 01:58:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20354 for ; Sun, 16 Jun 2002 01:58:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28044; Sun, 16 Jun 2002 01:58:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28013 for ; Sun, 16 Jun 2002 01:58:16 -0400 (EDT) Received: from web20801.mail.yahoo.com (web20801.mail.yahoo.com [216.136.226.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20339 for ; Sun, 16 Jun 2002 01:57:38 -0400 (EDT) Message-ID: <20020616055814.89055.qmail@web20801.mail.yahoo.com> Received: from [134.193.6.40] by web20801.mail.yahoo.com via HTTP; Sat, 15 Jun 2002 22:58:14 PDT Date: Sat, 15 Jun 2002 22:58:14 -0700 (PDT) From: senthil ayyasamy To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] draft-terrell-gwebs-vs-ieps-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org FYI: http://search.ietf.org/internet-drafts/draft-terrell-gwebs-vs-ieps-00.txt some of the recommendtations in the draft are unrealistic (Ex: creation of an universal protocol). But,some pointers from the draft are worth noting. The author compares fred's ieps requirement draft with his views.But,I dont know how his ideas can be fitted within TCP/IP. - Senthil __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jun 16 03:39:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29634 for ; Sun, 16 Jun 2002 03:39:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01433; Sun, 16 Jun 2002 03:38:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01398 for ; Sun, 16 Jun 2002 03:38:24 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29628 for ; Sun, 16 Jun 2002 03:37:47 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 16 Jun 2002 08:38:21 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: senthil ayyasamy cc: ieprep@ietf.org Subject: Re: [Ieprep] draft-terrell-gwebs-vs-ieps-00.txt In-reply-to: Your message of "Sat, 15 Jun 2002 22:58:14 PDT." <20020616055814.89055.qmail@web20801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Jun 2002 08:38:19 +0100 Message-ID: <7827.1024213099@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org one of the hardest things to do in this medium is to restrain oneself from responding to a piece of work that insists with no reservation and no compromise that 2+2 = 5 having stated that, this will be my very first and my very last public posting concerning the draft in question (and previous similar efforts). kindest regards, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jun 16 04:57:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00198 for ; Sun, 16 Jun 2002 04:57:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03752; Sun, 16 Jun 2002 04:57:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03721 for ; Sun, 16 Jun 2002 04:57:57 -0400 (EDT) Received: from web20810.mail.yahoo.com (web20810.mail.yahoo.com [216.136.226.199]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00195 for ; Sun, 16 Jun 2002 04:57:18 -0400 (EDT) Message-ID: <20020616085755.85999.qmail@web20810.mail.yahoo.com> Received: from [134.193.6.40] by web20810.mail.yahoo.com via HTTP; Sun, 16 Jun 2002 01:57:55 PDT Date: Sun, 16 Jun 2002 01:57:55 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-terrell-gwebs-vs-ieps-00.txt To: Ken Carlberg Cc: ieprep@ietf.org In-Reply-To: <7827.1024213099@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > one of the hardest things to do in this medium is to > restrain > oneself from responding to a piece of work that > insists with no > reservation and no compromise that 2+2 = 5 > > having stated that, this will be my very first and > my very last > public posting concerning the draft in question (and > previous > similar efforts). Ken's mail forced me to read his other works.To bolster ken's views: Read this http://www.cctec.com/maillists/nanog/historical/9908/msg00271.html . before commenting on his draft. - Senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 12:37:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26005 for ; Wed, 19 Jun 2002 12:37:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10630; Wed, 19 Jun 2002 12:35:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10598 for ; Wed, 19 Jun 2002 12:35:48 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25924 for ; Wed, 19 Jun 2002 12:35:08 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA07418; Wed, 19 Jun 2002 09:35:10 -0700 (PDT) Message-Id: <4.1.20020619113029.0b9509f0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 19 Jun 2002 11:35:07 -0500 To: "Berg, Dennis" , ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Ieprep] SIP-T/ISUP/SS7 interworking Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Direct from the (co)author of the RFC and drafts on SIP/ISUP/SS7 interworking >From: "Peterson, Jon" > >In addition to RFC3204 (which specifies MIME types for ISUP encapsulation) >you might want to check out the following: > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-02.txt >(framework) >http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-02.txt >(translation) >http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-00.txt >(specific to overlap) Hence, Fred (and all), I don't believe this WG requires a new ID in this area. Please let me know if these don't satisfy your ID requirement from the Interim meeting, but I do believe pointing at the following should proved the gap fillers we need. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Senior Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 14:19:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29842 for ; Wed, 19 Jun 2002 14:19:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19654; Wed, 19 Jun 2002 14:19:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19624 for ; Wed, 19 Jun 2002 14:19:39 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29836 for ; Wed, 19 Jun 2002 14:18:58 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:17:21 -0400 Message-ID: From: "Gunn, Janet NE" To: "'James M. Polk'" , "Berg, Dennis" , ieprep@ietf.org Subject: RE: [Ieprep] SIP-T/ISUP/SS7 interworking Date: Wed, 19 Jun 2002 14:17:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I have only skimmed the first, but I have read the second and third documents. None of them seem to address the mapping and translation of "Calling Party's Category" (CPC)(ISUP mandatory parameter), nor of "Precedence" (ISUP optional parameter). Both of these will probably be necessary to support "GETS-like" IP telephony emergency preparedness services. Am I missing something? -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, June 19, 2002 12:35 PM To: Berg, Dennis; ieprep@ietf.org Subject: [Ieprep] SIP-T/ISUP/SS7 interworking Direct from the (co)author of the RFC and drafts on SIP/ISUP/SS7 interworking >From: "Peterson, Jon" > >In addition to RFC3204 (which specifies MIME types for ISUP encapsulation) >you might want to check out the following: > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-02.txt >(framework) >http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-02.txt >(translation) >http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-00.txt >(specific to overlap) Hence, Fred (and all), I don't believe this WG requires a new ID in this area. Please let me know if these don't satisfy your ID requirement from the Interim meeting, but I do believe pointing at the following should proved the gap fillers we need. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Senior Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 15:18:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01396 for ; Wed, 19 Jun 2002 15:18:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22924; Wed, 19 Jun 2002 15:15:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22892 for ; Wed, 19 Jun 2002 15:15:42 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01362 for ; Wed, 19 Jun 2002 15:15:02 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA10943; Wed, 19 Jun 2002 12:15:02 -0700 (PDT) Message-Id: <4.1.20020619135309.0b238128@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 19 Jun 2002 14:14:59 -0500 To: "Gunn, Janet NE" , "Berg, Dennis" , ieprep@ietf.org From: "James M. Polk" Subject: RE: [Ieprep] SIP-T/ISUP/SS7 interworking Cc: "Peterson, Jon" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 02:17 PM 6/19/2002 -0400, Gunn, Janet NE wrote: >I have only skimmed the first, but I have read the second and third >documents. > >None of them seem to address the mapping and translation of "Calling Party's >Category" (CPC)(ISUP mandatory parameter), nor of "Precedence" (ISUP >optional parameter). > >Both of these will probably be necessary to support "GETS-like" IP telephony >emergency preparedness services. These are for what we need to reference and do the gap analysis on -- in IP. If there isn't a parameter or feature that we need, we need to include it in our Requirements ID. The tone of Fred's comments and requests were to put together a SIP-ISUP(SS7) doc - and the URLs are those. We're kinda in a catch-22 with Fred and the ADs not allowing us to specify a signaling mechanism before establishing the requirements for one, and that mechanism can't be included in other documents (the URLs below) until it's created through a requirement from this (or other) WG(s). Since we haven't reached group consensus on the requirement for this R-P Header (apparently) - how can it be included within other docs (even though it is already)? I'm momentarily bewildered and looking for guidance here (from the Chair and ADs at least). Allison/Scott -- Fred asked this WG to produce a SIP-ISUP doc for translating and overlap(ing) information from one topology to the other. The IDs listed below are the current work in that area. I understand that several below are also in WG or IESG Last Call. How should we address the requirement for GETS-like interoperation between IP and PSTN (ISUP/SS7) networks this WG should address without the IDs below getting altered (if nothing more than referencing the R-P Header ID)? This is interesting in light of side conversations that have questioned the need for the R-P Header at all, which could serve (once its allowed to proceed) as a solution to IEPREP's requirements for this translation. > >Am I missing something? Henning's R-P requirements ID could serve as the gap analysis if it were adjusted to reference the IDs listed below as what the IETF currently has (Architectures A, B and C), and where the IDs below are lacking (in meeting the requirements of IEPREP). Maybe.... > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Wednesday, June 19, 2002 12:35 PM >To: Berg, Dennis; ieprep@ietf.org >Subject: [Ieprep] SIP-T/ISUP/SS7 interworking > > >Direct from the (co)author of the RFC and drafts on SIP/ISUP/SS7 >interworking > >>From: "Peterson, Jon" >> >>In addition to RFC3204 (which specifies MIME types for ISUP encapsulation) >>you might want to check out the following: >> >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-02.txt >>(framework) >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-02.txt >>(translation) >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-00.txt >>(specific to overlap) > >Hence, Fred (and all), I don't believe this WG requires a new ID in this >area. Please let me know if these don't satisfy your ID requirement from >the Interim meeting, but I do believe pointing at the following should >proved the gap fillers we need. > > > > >************************************* >"People generally demand more respect for their own rights than they are >willing to allow for others" > >James M. Polk >Senior Consulting Engineer >Office of the CTO > >Cisco Systems >2200 East President George Bush Turnpike >Richardson, TX 75082 USA >w) 972.813.5208 >f) 972.813.5280 >www.cisco.com > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Senior Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 16:33:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02870 for ; Wed, 19 Jun 2002 16:33:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27081; Wed, 19 Jun 2002 16:33:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27048 for ; Wed, 19 Jun 2002 16:33:10 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02831 for ; Wed, 19 Jun 2002 16:32:29 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id 9767667103; Wed, 19 Jun 2002 17:08:35 -0400 (EDT) Date: Wed, 19 Jun 2002 16:32:37 -0400 Subject: Re: [Ieprep] SIP-T/ISUP/SS7 interworking Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep@ietf.org To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20020619135309.0b238128@localhost> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Wednesday, June 19, 2002, at 03:14 , James M. Polk wrote: > We're kinda in a catch-22 with Fred and the ADs not allowing us to > specify > a signaling mechanism before establishing the requirements for one, and > that mechanism can't be included in other documents (the URLs below) > until > it's created through a requirement from this (or other) WG(s). Sorry, but I don't see a "Catch-22", at least in the normal sense of that phrase (from the book of the same name). It is not unusual for an IETF WG to start with definition of high-level requirements (e.g. for a signalling mechanism's capabilities), then using those high-level requirements as a vehicle for talking with designers in other WGs about what kinds of capabilities are missing and perceived as needed. This sure seems pretty much like traditional top-down engineering to me, not a catch-22 where there is no way out. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 18:01:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04865 for ; Wed, 19 Jun 2002 18:01:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01794; Wed, 19 Jun 2002 18:00:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01753 for ; Wed, 19 Jun 2002 18:00:20 -0400 (EDT) Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04768 for ; Wed, 19 Jun 2002 17:59:39 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v32.21.) id r.25.294fec73 (3940); Wed, 19 Jun 2002 17:59:21 -0400 (EDT) Message-ID: <25.294fec73.2a4258b8@aol.com> Date: Wed, 19 Jun 2002 17:59:20 EDT Subject: Re: [Ieprep] SIP-T/ISUP/SS7 interworking To: Janet.Gunn@DynCorp.com, jmpolk@cisco.com, Dennis.Berg@DynCorp.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_25.294fec73.2a4258b8_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --part1_25.294fec73.2a4258b8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/19/02 2:20:19 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: > I have only skimmed the first, but I have read the second and third > documents. > > None of them seem to address the mapping and translation of "Calling Party's > Category" (CPC)(ISUP mandatory parameter), nor of "Precedence" (ISUP > optional parameter). > > Both of these will probably be necessary to support "GETS-like" IP telephony > emergency preparedness services. > > Am I missing something? > Mike Pierce comments: I would add to this list the draft for tel:uri, with -05 just issued. It seems that each of these drafts (SIP-T, ISUP mapping, overlap, tel:uri) each deal with one small aspect of interworking between ISUP and SIP. Some parts are simple mapping, some parts are encapsulation of information without the possibility of interpretation, and some are mapping with information lost. Each seems to leave out something that would likely be important in some particular situation, since each is only trying to address a limited application. I am afraid that these will never be able to satisfy the general need for ISUP to SIP interworking, since none of them appears to be chartered to do that. So they leave out things like "precedence", or "calling party's category" which are essential to interworking in at least some case. Or they do not take into account some realities about the existing PSTN. If it were within the charter of any one of these efforts to address the entire ISUP-SIP interworking issue, then any specific procedures to carry the priority level ("precedence" level in ISUP), whether in a new R-P header or some other way, would clearly belong in that effort. Mike Pierce Artel --part1_25.294fec73.2a4258b8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/19/02 2:20:19 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes:


I have only skimmed the first, but I have read the second and third
documents.

None of them seem to address the mapping and translation of "Calling Party's
Category" (CPC)(ISUP mandatory parameter), nor of "Precedence" (ISUP
optional parameter).

Both of these will probably be necessary to support "GETS-like" IP telephony
emergency preparedness services.

Am I missing something?


Mike Pierce comments:

I would add to this list the draft for tel:uri, with -05 just issued.

It seems that each of these drafts (SIP-T, ISUP mapping, overlap, tel:uri) each deal with one small aspect of interworking between ISUP and SIP. Some parts are simple mapping, some parts are encapsulation of information without the possibility of interpretation, and some are mapping with information lost. Each seems to leave out something that would likely be important in some particular situation, since each is only trying to address a limited application.

I am afraid that these will never be able to satisfy the general need for ISUP to SIP interworking, since none of them appears to be chartered to do that. So they leave out things like "precedence", or "calling party's category" which are essential to interworking in at least some case. Or they do not take into account some realities about the existing PSTN. If it were within the charter of any one of these efforts to address the entire ISUP-SIP interworking issue, then any specific procedures to carry the priority level ("precedence" level in ISUP), whether in a new R-P header or some other way, would clearly belong in that effort.

Mike Pierce
Artel
--part1_25.294fec73.2a4258b8_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 19 19:14:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06021 for ; Wed, 19 Jun 2002 19:14:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05174; Wed, 19 Jun 2002 19:14:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05140 for ; Wed, 19 Jun 2002 19:14:44 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06015 for ; Wed, 19 Jun 2002 19:14:04 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 19:14:43 -0400 Message-ID: From: "Folts, Harold" To: "'RJ Atkinson'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] SIP-T/ISUP/SS7 interworking Date: Wed, 19 Jun 2002 19:14:41 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Wednesday, June 19, 2002 4:33 PM > To: James M. Polk > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] SIP-T/ISUP/SS7 interworking > > > > It is not unusual for an IETF WG to start with definition of > high-level requirements (e.g. for a signalling mechanism's > capabilities), then using those high-level requirements as a > vehicle for talking with designers in > other WGs > about what kinds of capabilities are missing and perceived as needed. > > This sure seems pretty much like traditional top-down > engineering to me, not a catch-22 where there is no way out. Top down systems engineering it the most effective approach to any problem. That is what I am attempting with the ETS work. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jun 20 06:50:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23928 for ; Thu, 20 Jun 2002 06:50:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11668; Thu, 20 Jun 2002 06:49:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11640 for ; Thu, 20 Jun 2002 06:49:55 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23906 for ; Thu, 20 Jun 2002 06:49:13 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jun 2002 11:49:31 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jun 2002 11:49:30 +0100 Message-ID: <947.1024570170@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] new individual draft submission Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Hello, An individual contribution titled "Requirements for Authorized Emergency Communications Using Elastic Service" has been submitted to the I-D editor. Its an attempt to come up with some requirements that can be applied to elastic traffic/applications. and BEFORE anyone hits the panic button :-)....please read the following abstract for the portion of you that don't have the time to read all the drafts that get produced. The draft itself has some incomplete sections that can be either expanded or taken out. It would be great to have area experts/implementors participate -- we did this with the SMTP section and took a lessons-learned approach from an attempt last year to consider adding a priority field in SMTP. for those that do have time to read, and while waiting for the draft to perculate through the repositories, one can obtain a version from: http://www.cs.ucl.ac.uk/staff/k.carlberg/tmp/draft-carlberg-ieprep-elastic- requirements-00.txt -ken ----------------------------------------------------- Abstract The objective of this draft is to present a set of requirements to address requests by users of authorized emergency communications for better than best effort service for elastic service. We stress the word "request" versus guarantee, and we do NOT advocate broad sweeping changes to elastic applications. This document provides background information on emergency communications and presents suggested do's and don'ts in addressing the issue of requirements for elastic services. Finally, examples of requirements for specific applications are presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jun 20 07:15:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24797 for ; Thu, 20 Jun 2002 07:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12585; Thu, 20 Jun 2002 07:01:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12545 for ; Thu, 20 Jun 2002 07:01:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24349; Thu, 20 Jun 2002 07:00:29 -0400 (EDT) Message-Id: <200206201100.HAA24349@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, 20 Jun 2002 07:00:28 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-requirements-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Requirements for Emergency Telecommunication Capabilities in the Internet Author(s) : H. Folts, C. Beard Filename : draft-ietf-ieprep-requirements-00.txt Pages : 15 Date : 19-Jun-02 This document outlines requirements that need to be met in IP-based networks to enable and support communications for National Security/Emergency Preparedness (NS/EP) operations. It provides a basis from which an emergency telecommunications service can be negotiated and provides a set of requirements that should be met for acceptable emergency telecommunication capabilities for disaster recovery operations. The focus here is on network requirements, rather than requirements for particular applications. The requirements are general, functional, and are intended to provide wide latitude in implementation options for service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-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-requirements-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-requirements-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: <20020619122937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020619122937.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 21 06:18:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06181 for ; Fri, 21 Jun 2002 06:18:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02184; Fri, 21 Jun 2002 06:18:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02140 for ; Fri, 21 Jun 2002 06:18:15 -0400 (EDT) Received: from web20801.mail.yahoo.com (web20801.mail.yahoo.com [216.136.226.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06161 for ; Fri, 21 Jun 2002 06:17:33 -0400 (EDT) Message-ID: <20020621101812.32193.qmail@web20801.mail.yahoo.com> Received: from [134.193.6.40] by web20801.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 03:18:12 PDT Date: Fri, 21 Jun 2002 03:18:12 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] new individual draft submission To: Ken Carlberg Cc: ieprep@ietf.org In-Reply-To: <564.1024652819@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ken, section 4.2.1 on SMTP talks about creating a possible name space whereby a client may mark a message with a given priority and process of increasing the forwarding rate of emergency related messages. Some clarifications: 1.How an MTA interpret the emergency related message at the destination.Possibilities might occur where different priority messages originate from same destination or different destination. 2.Cant we just use *SMTP Service Extensions*,RFC-1869 for defining priority than creating a new name space. thanks in advance, -senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 21 07:13:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07413 for ; Fri, 21 Jun 2002 07:13:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05253; Fri, 21 Jun 2002 07:13:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05218 for ; Fri, 21 Jun 2002 07:13:26 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07407 for ; Fri, 21 Jun 2002 07:12:43 -0400 (EDT) Received: from 213.78.71.47 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 21 Jun 2002 12:13:04 +0100 From: Ian Brown To: senthil ayyasamy , Ken Carlberg Cc: ieprep Subject: RE: [Ieprep] new individual draft submission Date: Fri, 21 Jun 2002 12:14:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020621101812.32193.qmail@web20801.mail.yahoo.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > 1.How an MTA interpret the emergency related message > at the destination.Possibilities might occur where > different priority messages originate from same > destination or different destination. It's up to MTAs how they interpret any priority label. > 2.Cant we just use *SMTP Service Extensions*,RFC-1869 > for defining priority than creating a new name space. An extension would be a reasonable implementation method, but would still need a way to describe what priority level was being requested using the extension. One way to do that would be to use a namespace system such as that proposed by James Polk for his resource priority header. But we are specifying requirements in this draft, not mechanisms to meet them (while mentioning protocol features that might be used). Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 21 11:33:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17355 for ; Fri, 21 Jun 2002 11:33:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18053; Fri, 21 Jun 2002 11:33:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18021 for ; Fri, 21 Jun 2002 11:33:27 -0400 (EDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17342 for ; Fri, 21 Jun 2002 11:32:44 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 11:33:23 -0400 Message-ID: From: "Nguyen, An" To: "'Ken Carlberg'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] new individual draft submission Date: Fri, 21 Jun 2002 11:33:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ken, Because this contribution is about the elastic service for emergency communications, do you think we should have a sentence or a paragraph that talks about going from high speed codecs (e.g., G.711) to low codecs (e.g., G.723.1)in times of traffic congestion for authorized emergency workers instead of dropping the calls completely? Of course, this will affect the QoS of the calls. I don't know if it is in the scope of this document. An -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Thursday, June 20, 2002 6:50 AM To: ieprep@ietf.org Subject: [Ieprep] new individual draft submission Hello, An individual contribution titled "Requirements for Authorized Emergency Communications Using Elastic Service" has been submitted to the I-D editor. Its an attempt to come up with some requirements that can be applied to elastic traffic/applications. and BEFORE anyone hits the panic button :-)....please read the following abstract for the portion of you that don't have the time to read all the drafts that get produced. The draft itself has some incomplete sections that can be either expanded or taken out. It would be great to have area experts/implementors participate -- we did this with the SMTP section and took a lessons-learned approach from an attempt last year to consider adding a priority field in SMTP. for those that do have time to read, and while waiting for the draft to perculate through the repositories, one can obtain a version from: http://www.cs.ucl.ac.uk/staff/k.carlberg/tmp/draft-carlberg-ieprep-elastic- requirements-00.txt -ken ----------------------------------------------------- Abstract The objective of this draft is to present a set of requirements to address requests by users of authorized emergency communications for better than best effort service for elastic service. We stress the word "request" versus guarantee, and we do NOT advocate broad sweeping changes to elastic applications. This document provides background information on emergency communications and presents suggested do's and don'ts in addressing the issue of requirements for elastic services. Finally, examples of requirements for specific applications are presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 21 13:27:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23355 for ; Fri, 21 Jun 2002 13:27:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26386; Fri, 21 Jun 2002 13:26:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26352 for ; Fri, 21 Jun 2002 13:26:51 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23298 for ; Fri, 21 Jun 2002 13:26:09 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id B625767103; Fri, 21 Jun 2002 14:02:31 -0400 (EDT) Date: Fri, 21 Jun 2002 13:26:18 -0400 Subject: Re: [Ieprep] new individual draft submission Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Ken Carlberg'" , ieprep@ietf.org To: "Nguyen, An" From: RJ Atkinson In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 21, 2002, at 11:33 , Nguyen, An wrote: > Ken, > > Because this contribution is about the elastic service for emergency > communications, do you think we should have a sentence or a paragraph > that > talks about going from high speed codecs (e.g., G.711) to low codecs > (e.g., > G.723.1)in times of traffic congestion for authorized emergency workers > instead of dropping the calls completely? Of course, this will affect > the > QoS of the calls. I don't know if it is in the scope of this document. That kind of thinking makes sense, at least as an example of one way some operators or users might deal with congestion, etc... I'm not a fan of levying any implementation-specific requirements onto operators, figuring that different operators have different networks and might choose different mechanisms/implementations to meet whatever high-level requirements might exist. But examples seem fine... Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jun 22 11:49:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29046 for ; Sat, 22 Jun 2002 11:49:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22954; Sat, 22 Jun 2002 11:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22922 for ; Sat, 22 Jun 2002 11:49:09 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29037 for ; Sat, 22 Jun 2002 11:48:29 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 22 Jun 2002 16:48:55 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: "Nguyen, An" cc: ieprep@ietf.org Subject: Re: [Ieprep] new individual draft submission In-reply-to: Your message of "Fri, 21 Jun 2002 11:33:21 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jun 2002 16:48:53 +0100 Message-ID: <24650.1024760933@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Hello An, > Because this contribution is about the elastic service for emergency > communications, do you think we should have a sentence or a paragraph that > talks about going from high speed codecs (e.g., G.711) to low codecs (e.g., > G.723.1)in times of traffic congestion for authorized emergency workers > instead of dropping the calls completely? Of course, this will affect the > QoS of the calls. I don't know if it is in the scope of this document. a nice head scratcher. I'm probably being picky, but my feeling is that the specific example above is out of scope of the document because there isn't an automated means in your description of going from something like G.711 to G.723. Lacking something in the application or a server/gateway middlebox to accomplish the downgrade, it relies on a person-in-the-loop action. however, a generalization of your example IS something I can put in the issues portion of the draft to convey that the placement of a label doesn't automatically mean better service in the form of additional resources. instead, it can simply be a trigger for achieving a different type of service -- e.g., a lower form of end-to-end QoS in order to achieve communication. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 24 10:46:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09999 for ; Mon, 24 Jun 2002 10:46:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19682; Mon, 24 Jun 2002 10:46:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19650 for ; Mon, 24 Jun 2002 10:46:15 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09924 for ; Mon, 24 Jun 2002 10:45:31 -0400 (EDT) Received: from 213.78.79.90 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jun 2002 15:45:42 +0100 From: Ian Brown To: ieprep Date: Mon, 24 Jun 2002 15:46:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Ieprep] IPsec vs TLS for SIP message protection Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit I had some feedback from Eric Rescorla that he considers IPSec much more suitable for use in protecting SIP messages in a resource-constrained environment than TLS due to its better Denial of Service protection. However, not all SIP devices will support IPSec (but should support TLS). What do people think about specifying that IPSec should be used where available in preference to TLS? Thanks, Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 24 14:04:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21580 for ; Mon, 24 Jun 2002 14:04:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01309; Mon, 24 Jun 2002 14:03:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01280 for ; Mon, 24 Jun 2002 14:03:32 -0400 (EDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21467 for ; Mon, 24 Jun 2002 14:02:48 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 14:03:30 -0400 Message-ID: From: "Nguyen, An" To: "'Ian Brown'" Cc: ieprep Subject: RE: [Ieprep] IPsec vs TLS for SIP message protection Date: Mon, 24 Jun 2002 14:03:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ian, My understanding is that TLS is more interoperable than IPSec because the TLS architecture is much simpler. TLS deals with transport layers and IPsec with IP. IETF has so many flavors of IPSec. And getting all these to talk to one another is more of a political issue than technical. I would like to know technically how IPSec protects SIP messages better than TLS as far as DoS is concerned. Personally I think IPsec and TLS are good for SIP and other applications. Regards, An -----Original Message----- From: Ian Brown [mailto:I.Brown@cs.ucl.ac.uk] Sent: Monday, June 24, 2002 10:47 AM To: ieprep Subject: [Ieprep] IPsec vs TLS for SIP message protection I had some feedback from Eric Rescorla that he considers IPSec much more suitable for use in protecting SIP messages in a resource-constrained environment than TLS due to its better Denial of Service protection. However, not all SIP devices will support IPSec (but should support TLS). What do people think about specifying that IPSec should be used where available in preference to TLS? Thanks, Ian. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 24 16:50:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29801 for ; Mon, 24 Jun 2002 16:50:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11453; Mon, 24 Jun 2002 16:50:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11418 for ; Mon, 24 Jun 2002 16:50:48 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29788 for ; Mon, 24 Jun 2002 16:50:00 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5OKofxc024489; Mon, 24 Jun 2002 16:50:41 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5OKoepf019003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Jun 2002 16:50:41 -0400 (EDT) Message-ID: <3D1785F7.3010802@cs.columbia.edu> Date: Mon, 24 Jun 2002 16:49:59 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Brown CC: ieprep Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Is this true even for existing signaling "trunks", i.e., established TLS connections that are re-used for many SIP sessions? Given the practical problems of deploying IPsec between parties that haven't "met", I'm a bit concerned about this step. There is a good reason why most people are implementing TLS. Ian Brown wrote: > I had some feedback from Eric Rescorla that he considers IPSec much more > suitable for use in protecting SIP messages in a resource-constrained > environment than TLS due to its better Denial of Service protection. > However, not all SIP devices will support IPSec (but should support TLS). > > What do people think about specifying that IPSec should be used where > available in preference to TLS? > > Thanks, > > Ian. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jun 24 17:01:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00574 for ; Mon, 24 Jun 2002 17:01:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13791; Mon, 24 Jun 2002 17:01:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13683 for ; Mon, 24 Jun 2002 17:01:52 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00527 for ; Mon, 24 Jun 2002 17:01:06 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id B8B0E67103; Mon, 24 Jun 2002 17:36:58 -0400 (EDT) Date: Mon, 24 Jun 2002 17:00:17 -0400 Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Ian Brown'" , ieprep To: "Nguyen, An" From: RJ Atkinson In-Reply-To: Message-Id: <6311114E-87B5-11D6-9D0A-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Monday, June 24, 2002, at 02:03 , Nguyen, An wrote: > IETF has so many flavors of IPSec. And getting all these to talk to > one another is more of a political issue than technical. anh A^n, If one defines "IPsec" to include dynamic key management (e.g. ISAKMP/IKE), then interoperability has been a real problem. IKE is quite complex. Moreover, IKE is unstable in the standards sense. It will either be replaced by IKEv2 or JFK or some other proposal -- because IKEv1 is widely believed to have a range of problems -- including security anomalies. However, if one defines "IPsec" (as I do) to only mean AH and ESP, then interoperability has not been a significant problem since 1996. Commercial interoperable implementations of AH and ESP are pretty widely available today, not just in firewall products, but also in commercial operating systems (e.g. Sun Solaris). > I would like to know technically how IPSec protects SIP messages better > than > TLS as far as DoS is concerned. - TLS does not protect the IP header, as AH does. - TLS does not protect the actual TCP header, as either ESP or AH does. - TLS does not protect any UDP-based traffic, as either ESP or AH does. - Unlike ESP, the US has universally permitted export of AH because AH is authentication-only, while ESP can also be used for confidentiality. There are a number of documented attack methods [Bellovin89] on the TCP header (e.g. send a forged RST to take down a session) that ESP or AH can protect against that TLS cannot protect against. I'm not so much arguing for or against using ESP/AH in the context of SIP; I am trying to clear up the misunderstandings that appear to exist on this mailing list about the differences in the security properties provided by TLS, ESP, and AH. Regards, Ran rja@extremenetworks.com PS: and yes, I'm the guy who invented ESP and AH in the first place, and lead the team at NRL with the first ESP/AH implementation (in 4.4 BSD), though I am not working on security stuff these days... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 01:56:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14481 for ; Tue, 25 Jun 2002 01:56:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17260; Tue, 25 Jun 2002 01:53:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10352 for ; Tue, 25 Jun 2002 01:06:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13807 for ; Tue, 25 Jun 2002 01:05:57 -0400 (EDT) Received: from FRED-W2K6.cisco.com (rtp-vpn2-81.cisco.com [10.82.240.81]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5P557L7027196 for ; Mon, 24 Jun 2002 22:06:06 -0700 (PDT) Message-Id: <5.1.1.6.2.20020624213500.028234b8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 24 Jun 2002 21:35:07 -0700 To: ieprep@ietf.org From: Internet-Drafts@ietf.org (by way of Fred Baker ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] I-D ACTION:draft-carlberg-ieprep-elastic-requirements-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Authorized Emergency Communications Using Elastic Service Author(s) : K. Carlberg, I. Brown Filename : draft-carlberg-ieprep-elastic-requirements-00.txt Pages : 13 Date : 20-Jun-02 The objective of this draft is to present a set of requirements to address requests by users of authorized emergency communications for better than best effort service for elastic service. We stress the word 'request' versus guarantee, and we do NOT advocate broad sweeping changes to elastic applications. This document provides background information on emergency communications and presents suggested do's and don'ts in addressing the issue of requirements for elastic services. Finally, examples of requirements for specific applications are presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carlberg-ieprep-elastic-requirements-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-carlberg-ieprep-elastic-requirements-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-carlberg-ieprep-elastic-requirements-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: <20020620141716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carlberg-ieprep-elastic-requirements-00.txt _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 07:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29868 for ; Tue, 25 Jun 2002 07:04:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03853; Tue, 25 Jun 2002 07:04:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03816 for ; Tue, 25 Jun 2002 07:04:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29629; Tue, 25 Jun 2002 07:03:30 -0400 (EDT) Message-Id: <200206251103.HAA29629@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, 25 Jun 2002 07:03:30 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Recommended Packet Marking Policy Author(s) : F. Baker Filename : draft-ietf-ieprep-packet-marking-policy-00.txt Pages : 17 Date : 24-Jun-02 This paper summarizes a recommended correlation of applications to Differentiated Service Code Points. There is no intrinsic requirement that individual DSCPs correspond to given applications, but as a policy it is useful if they can be applied consistently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-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-packet-marking-policy-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-packet-marking-policy-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: <20020624144040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-packet-marking-policy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-packet-marking-policy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624144040.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 07:08:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29998 for ; Tue, 25 Jun 2002 07:08:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03629; Tue, 25 Jun 2002 07:02:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03596 for ; Tue, 25 Jun 2002 07:02:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29280; Tue, 25 Jun 2002 07:02:04 -0400 (EDT) Message-Id: <200206251102.HAA29280@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, 25 Jun 2002 07:02:04 -0400 Subject: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Emergency Preparedness Services in a Differentiated Services Domain Author(s) : S. Talauliker, C. Beard Filename : draft-talauliker-ieprep-diffserv-00.txt Pages : 9 Date : 24-Jun-02 The international community needs advice as to what standards to rely on for the operational implementation of services for Emergency Preparedness. This draft outlines the best current practices to provide deterministic behavior of Internet applications during emergencies using Differentiated Services. It should be noted that there can be more than one suitable approach and this draft only describes what can be done with the existing Differentiated Services architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-talauliker-ieprep-diffserv-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-talauliker-ieprep-diffserv-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-talauliker-ieprep-diffserv-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: <20020624143740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-talauliker-ieprep-diffserv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-talauliker-ieprep-diffserv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143740.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 07:25:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00558 for ; Tue, 25 Jun 2002 07:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04522; Tue, 25 Jun 2002 07:26:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04488 for ; Tue, 25 Jun 2002 07:25:58 -0400 (EDT) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00552 for ; Tue, 25 Jun 2002 07:25:14 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g5PBMqn05338 for ; Tue, 25 Jun 2002 12:22:52 +0100 Received: from ([10.153.25.53]) by Baltimore-FW1; Fri, 21 Dec 2001 12:24:54 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 25 Jun 2002 12:19:42 +0100 Received: from ([10.153.25.10]) by Baltimore-FW1; Fri, 21 Dec 2001 12:24:52 +0000 (GMT) Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA26032; Tue, 25 Jun 2002 12:25:51 +0100 Message-ID: <3D185303.46878A9@baltimore.ie> Date: Tue, 25 Jun 2002 12:24:51 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: RJ Atkinson CC: "Nguyen, An" , "'Ian Brown'" , ieprep Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection References: <6311114E-87B5-11D6-9D0A-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Isn't there on-going work on payload level protection of SIP messages? If so, then s/mime &/or pgp (or whatever the SIP folks develop) should also be considered. Stephen. RJ Atkinson wrote: > > On Monday, June 24, 2002, at 02:03 , Nguyen, An wrote: > > IETF has so many flavors of IPSec. And getting all these to talk to > > one another is more of a political issue than technical. > > anh A^n, > > If one defines "IPsec" to include dynamic key management (e.g. > ISAKMP/IKE), > then interoperability has been a real problem. IKE is quite complex. > Moreover, IKE is unstable in the standards sense. It will either be > replaced > by IKEv2 or JFK or some other proposal -- because IKEv1 is widely > believed > to have a range of problems -- including security anomalies. > > However, if one defines "IPsec" (as I do) to only mean AH and ESP, > then interoperability has not been a significant problem since 1996. > Commercial interoperable implementations of AH and ESP are pretty widely > available today, not just in firewall products, but also in commercial > operating systems (e.g. Sun Solaris). > > > I would like to know technically how IPSec protects SIP messages better > > than > > TLS as far as DoS is concerned. > > - TLS does not protect the IP header, as AH does. > - TLS does not protect the actual TCP header, as either ESP or AH does. > - TLS does not protect any UDP-based traffic, as either ESP or AH does. > - Unlike ESP, the US has universally permitted export of AH because > AH is authentication-only, while ESP can also be used for > confidentiality. > > There are a number of documented attack methods [Bellovin89] on the TCP > header > (e.g. send a forged RST to take down a session) that ESP or AH can > protect > against that TLS cannot protect against. > > I'm not so much arguing for or against using ESP/AH in the context of > SIP; > I am trying to clear up the misunderstandings that appear to exist > on this mailing list about the differences in the security properties > provided by TLS, ESP, and AH. > > Regards, > > Ran > rja@extremenetworks.com > > PS: and yes, I'm the guy who invented ESP and AH in the first place, > and lead the team at NRL with the first ESP/AH implementation (in > 4.4 BSD), > though I am not working on security stuff these days... > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 08:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02625 for ; Tue, 25 Jun 2002 08:30:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06865; Tue, 25 Jun 2002 08:24:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06831 for ; Tue, 25 Jun 2002 08:24:17 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02373 for ; Tue, 25 Jun 2002 08:23:32 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5PCOBxc027635; Tue, 25 Jun 2002 08:24:11 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5PCNnpf015386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jun 2002 08:23:50 -0400 (EDT) Message-ID: <3D1860AC.5030003@cs.columbia.edu> Date: Tue, 25 Jun 2002 08:23:08 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: RJ Atkinson , "Nguyen, An" , "'Ian Brown'" , ieprep Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection References: <6311114E-87B5-11D6-9D0A-00039357A82A@extremenetworks.com> <3D185303.46878A9@baltimore.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > Isn't there on-going work on payload level protection of SIP > messages? > > If so, then s/mime &/or pgp (or whatever the SIP folks develop) > should also be considered. > Indeed; S/MIME is specified in the current draft that will become the successor of RFC 2543. After wasting far too much time trying to argue which is the best mechanism, most of the working group seems to have reached the conclusion that S/MIME, TLS and IPsec all have strengths in particular deployment scenarios and that we'll see a combination of them in practice. S/MIME is no replacement for IPsec or TLS, since it is an end-to-end encryption mechanism that needs to leave a number of header fields unencrypted. (The converse is true, too.) I suspect that this working group may have better things to do than rehash those arguments. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 08:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03392 for ; Tue, 25 Jun 2002 08:50:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08458; Tue, 25 Jun 2002 08:50:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08424 for ; Tue, 25 Jun 2002 08:50:52 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03325 for ; Tue, 25 Jun 2002 08:50:07 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g5PCood00630 for ieprep@ietf.org; Tue, 25 Jun 2002 08:50:50 -0400 (EDT) Date: Tue, 25 Jun 2002 08:50:50 -0400 (EDT) From: Scott Bradner Message-Id: <200206251250.g5PCood00630@newdev.harvard.edu> To: ieprep@ietf.org Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org AD hat on this thread has been interesting but out of scope for this working group. this group is supposed to be developing requirements not debating solutions - focusing on solutions at this point is out of scope but also limiting in that understanding what a suggested solution can offer tends to redefine the requirement to meet the solution if IEPREP decides that all packets need to be painted to match the new national emergency alert color scheme then say so (but you better provide strong reasons :-) ) - do not debate how SIP, or anything else, might do the job. so don't leap to protocols, because doing so has tends to obscure important requirements that are actually needed. OK, you want more resistance to DoS attack than might be characterized by a TLS-style channel security, say what you *need*. But leaping to the IPsec story might dictate an approach to authentication that might not be necessary or sufficient to emergency services call authentication and authorization - who has written down the characteristics of those specific requirements? The present debate has been too generic. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 08:56:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03686 for ; Tue, 25 Jun 2002 08:56:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08676; Tue, 25 Jun 2002 08:54:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08639 for ; Tue, 25 Jun 2002 08:54:22 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03522 for ; Tue, 25 Jun 2002 08:53:37 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 08:54:20 -0400 Message-ID: From: "Nguyen, An" To: "'RJ Atkinson'" Cc: "'Ian Brown'" , ieprep Subject: RE: [Ieprep] IPsec vs TLS for SIP message protection Date: Tue, 25 Jun 2002 08:54:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ran, >- TLS does not protect the IP header, as AH does. >- TLS does not protect the actual TCP header, as either ESP or AH does. >- TLS does not protect any UDP-based traffic, as either ESP or AH does. >- Unlike ESP, the US has universally permitted export of AH because AH is authentication-only, while ESP can also be used for confidentiality. I am still not sure how protecting IP header and datagram with AH and ESP is better (than TLS) as far as Denial of Service attacks are concerned. I am sorry I missed something here. To me, DoS means bringing servers down to their knees by hackers (i.e., exhaust CPU resources) so that servers can not provide any service to their clients. Maybe we can discuss this offline. Regards, An _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 09:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05942 for ; Tue, 25 Jun 2002 09:57:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11686; Tue, 25 Jun 2002 09:47:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11652 for ; Tue, 25 Jun 2002 09:47:09 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05497 for ; Tue, 25 Jun 2002 09:46:23 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 3211E67103; Tue, 25 Jun 2002 10:23:22 -0400 (EDT) Date: Tue, 25 Jun 2002 09:46:35 -0400 Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: "Nguyen, An" From: RJ Atkinson In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Tuesday, June 25, 2002, at 08:54 , Nguyen, An wrote: > Ran, > >> - TLS does not protect the IP header, as AH does. >> - TLS does not protect the actual TCP header, as either ESP or AH does. >> - TLS does not protect any UDP-based traffic, as either ESP or AH does. >> - Unlike ESP, the US has universally permitted export of AH because > AH is authentication-only, while ESP can also be used for > confidentiality. > > I am still not sure how protecting IP header and datagram with AH and > ESP is > better (than TLS) as far as Denial of Service attacks are concerned. Alice and Bob are hosts. Alice and Bob are running SIP over TCP. Adversary Charlie sends a forged message containing a TCP RST for Alice & Bob's TCP session to either Alice or Bob or both. That session then disappears. This is a denial-of-service attack. The adversary took away Alice and Bob's SIP session, which also removes their ability to send signalling traffic for voice calls -- and which by extension might remove or reduce their ability to send/receive certain voice calls. > To me, DoS means bringing servers down to > their knees by hackers (i.e., exhaust CPU resources) so that servers > can not > provide any service to their clients. Maybe we can discuss this offline. Your definition is OK if you qualify it with "CPU denial-of-service attack". There are many flavours of denial-of-service attack. The one I outline above might be called a "network denial-of-service attack". To give an example that is both a CPU denial-of-service attack and a network denial-of-service attack, consider that Charlie sends forged TCP SYN packets really from Charlie, claiming to be from Alice, and destined for Bob. Because Bob and Alice don't use AH or ESP to authenticate all their network sessions, Bob erroneously believes that this is a legitimate attempt to start a session by Alice (spends Bob's CPU generating a response, then spends Alice's CPU responding to Bob's response; and consuming TCP state for both of them). This is a variant on the now well-known TCP SYN flood attack. Feel free to drop me a unicast note if you want to chat more. Cheers, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 13:25:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17004 for ; Tue, 25 Jun 2002 13:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28961; Tue, 25 Jun 2002 13:23:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28927 for ; Tue, 25 Jun 2002 13:23:37 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16904 for ; Tue, 25 Jun 2002 13:22:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Mu2O-000Kwu-00 for ieprep@ietf.org; Tue, 25 Jun 2002 10:23:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ieprep@ietf.org Message-Id: Date: Tue, 25 Jun 2002 10:23:32 -0700 Content-Transfer-Encoding: 7bit Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit this looks a lot like protocol and not like requirements Title : Recommended Packet Marking Policy Author(s) : F. Baker Filename : draft-ietf-ieprep-packet-marking-policy-00.txt Pages : 17 Date : 24-Jun-02 given the charter and scott's recent posting of allison-sounding words, please explan how this got to be an ieprep wg document. randy _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 14:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22970 for ; Tue, 25 Jun 2002 14:58:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08786; Tue, 25 Jun 2002 14:59:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08750 for ; Tue, 25 Jun 2002 14:59:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22918 for ; Tue, 25 Jun 2002 14:58:29 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-450.cisco.com [10.21.97.194]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5PIvqL1003137; Tue, 25 Jun 2002 11:57:52 -0700 (PDT) Message-Id: <5.1.1.6.2.20020625115636.02571640@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 25 Jun 2002 11:57:51 -0700 To: Randy Bush From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Cc: ieprep@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:23 AM 6/25/2002 -0700, Randy Bush wrote: >given the charter and scott's recent posting of allison-sounding words, >please explan how this got to be an ieprep wg document. Please go re-read the charter. The working group is supposed to come up with requirements, and one or more BCPs of specific recommendations - no new protocols, but instructions on how to use existing ones - to meet ETS needs. This is absolutely within charter. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 16:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26336 for ; Tue, 25 Jun 2002 16:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13761; Tue, 25 Jun 2002 16:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13727 for ; Tue, 25 Jun 2002 16:04:51 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26240 for ; Tue, 25 Jun 2002 16:04:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17MwYT-0003Nv-00; Tue, 25 Jun 2002 13:04:49 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Fred Baker Cc: ieprep@ietf.org Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt References: <5.1.1.6.2.20020625115636.02571640@mira-sjcm-4.cisco.com> Message-Id: Date: Tue, 25 Jun 2002 13:04:49 -0700 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit >> given the charter and scott's recent posting of allison-sounding words, >> please explan how this got to be an ieprep wg document. > Please go re-read the charter. The working group is supposed to come up > with requirements, and one or more BCPs of specific recommendations - no > new protocols, but instructions on how to use existing ones - to meet ETS > needs. > This is absolutely within charter. > Date: Tue, 25 Jun 2002 08:50:50 -0400 (EDT) > From: Scott Bradner > To: ieprep@ietf.org > Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection > > AD hat on > > this thread has been interesting but out of scope for this working group. > > this group is supposed to be developing requirements not debating solutions > - focusing on solutions at this point is out of scope but also limiting in > that understanding what a suggested solution can offer tends to redefine > the requirement to meet the solution _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 16:11:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26600 for ; Tue, 25 Jun 2002 16:11:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13810; Tue, 25 Jun 2002 16:05:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13772 for ; Tue, 25 Jun 2002 16:05:08 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26250 for ; Tue, 25 Jun 2002 16:04:23 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA21861; Tue, 25 Jun 2002 13:04:26 -0700 (PDT) Message-Id: <4.1.20020623134228.07f165f8@localhost> Message-Id: <4.1.20020623134228.07f165f8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 23 Jun 2002 14:01:53 -0500 To: Ken Carlberg , "Nguyen, An" From: "James M. Polk" Subject: Re: [Ieprep] new individual draft submission Cc: ieprep@ietf.org In-Reply-To: <24650.1024760933@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:48 PM 6/22/2002 +0100, Ken Carlberg wrote: >Hello An, > >> Because this contribution is about the elastic service for emergency >> communications, do you think we should have a sentence or a paragraph that >> talks about going from high speed codecs (e.g., G.711) to low codecs (e.g., >> G.723.1)in times of traffic congestion for authorized emergency workers >> instead of dropping the calls completely? Of course, this will affect the >> QoS of the calls. I don't know if it is in the scope of this document. > >a nice head scratcher. I'm probably being picky, but my feeling is that >the specific example above is out of scope of the document because there >isn't an automated means in your description of going from something like >G.711 to G.723. Lacking something in the application or a server/gateway >middlebox to accomplish the downgrade, it relies on a person-in-the-loop >action. The interface in the middle (that has the active session in question) where congestion is occurring must notify (the UAs directly) or something else to notify the UAs of the congestion situation and to ask/request/mandate that session downgrade to use less BW. Hmmmm..... SIP already has the capability to alter an existing session through reINVITE with different SDP parameters (such as using a lower BW codec). Currently the UAS can either accept this request or reject it, or propose an again different SDP (parameters). The issue you described above lacks the ability of the network to inform/notify a UA (or both) that an RTP session it has active needs to be adjusted, because the network isn't a stateful component in SIP architectures, nor will it know (possibly ever under any circumstances) the particulars of a (any) session traversing it. This should be easy with a Call Agent Architecture, and perhaps the comment in the ID can state something to that affect (i.e. "... in the case where the network is statefully aware of the endpoints communicating via this x congested interface, to notify them that a codec downgrade is (about to or going to) occur (provided the auditcapabilities of each endpoint or termination) *can* perform this function)...") > >however, a generalization of your example IS something I can put in the >issues portion of the draft to convey that the placement of a label >doesn't automatically mean better service in the form of additional >resources. instead, it can simply be a trigger for achieving a different >type of service -- e.g., a lower form of end-to-end QoS in order to achieve >communication. > >-ken > > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Senior Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 20:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04632 for ; Tue, 25 Jun 2002 20:38:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26491; Tue, 25 Jun 2002 19:37:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26457 for ; Tue, 25 Jun 2002 19:37:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03362 for ; Tue, 25 Jun 2002 19:37:11 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-357.cisco.com [10.21.65.101]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5PNbIL1020137; Tue, 25 Jun 2002 16:37:20 -0700 (PDT) Message-Id: <5.1.1.6.2.20020625163439.027b43f0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 25 Jun 2002 16:37:14 -0700 To: Randy Bush From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Cc: ieprep@ietf.org In-Reply-To: References: <5.1.1.6.2.20020625115636.02571640@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Great, Randy. Now go back and read the parts of Scott's message that you didn't quote. The particulars of adding protocol information elements to SIP, that are not now present and may be the wrong way to architect the solution, are beyond our charter. Making a BCP identifying what DSCP values to use - from existing standardized PHBs - is specifically part of our charter. At 01:04 PM 6/25/2002 -0700, Randy Bush wrote: > >> given the charter and scott's recent posting of allison-sounding words, > >> please explan how this got to be an ieprep wg document. > > Please go re-read the charter. The working group is supposed to come up > > with requirements, and one or more BCPs of specific recommendations - no > > new protocols, but instructions on how to use existing ones - to meet ETS > > needs. > > This is absolutely within charter. > > > Date: Tue, 25 Jun 2002 08:50:50 -0400 (EDT) > > From: Scott Bradner > > To: ieprep@ietf.org > > Subject: Re: [Ieprep] IPsec vs TLS for SIP message protection > > > > AD hat on > > > > this thread has been interesting but out of scope for this working group. > > > > this group is supposed to be developing requirements not debating solutions > > - focusing on solutions at this point is out of scope but also limiting in > > that understanding what a suggested solution can offer tends to redefine > > the requirement to meet the solution _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jun 25 21:00:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04966 for ; Tue, 25 Jun 2002 21:00:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29500; Tue, 25 Jun 2002 21:01:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29466 for ; Tue, 25 Jun 2002 21:01:01 -0400 (EDT) Received: from web20801.mail.yahoo.com (web20801.mail.yahoo.com [216.136.226.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04958 for ; Tue, 25 Jun 2002 21:00:17 -0400 (EDT) Message-ID: <20020626010059.22025.qmail@web20801.mail.yahoo.com> Received: from [134.193.6.40] by web20801.mail.yahoo.com via HTTP; Tue, 25 Jun 2002 18:00:59 PDT Date: Tue, 25 Jun 2002 18:00:59 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt To: ieprep@ietf.org In-Reply-To: <200206251103.HAA29629@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Fred, Section 3 talks about reflexive DSCP policy.If i am correct , the draft recommends reflexive DSCP policy for providing uniform service differentiation in both the directions as diffserv is undirectional . But, it can be done more easily by configuring same DSCP in both the directions. Also,I have a slight inkling that reflexive DSCP will be unnecessary for emergency services.Both the sender and receiver will clearly know their priority in advance .hence ,they can very well use same DSCP code point in both the directions .Its just a thought ,I may be wrong. - Senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 03:01:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05670 for ; Wed, 26 Jun 2002 03:01:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02882; Wed, 26 Jun 2002 02:59:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02848 for ; Wed, 26 Jun 2002 02:59:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05573 for ; Wed, 26 Jun 2002 02:58:51 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-54.cisco.com [10.21.96.54]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5Q6woL5027737; Tue, 25 Jun 2002 23:59:03 -0700 (PDT) Message-Id: <5.1.1.6.2.20020625234641.0272da30@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 25 Jun 2002 23:54:14 -0700 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Cc: ieprep@ietf.org In-Reply-To: <20020626010059.22025.qmail@web20801.mail.yahoo.com> References: <200206251103.HAA29629@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 06:00 PM 6/25/2002 -0700, senthil ayyasamy wrote: >it can be done more easily by configuring same DSCP in both the directions. BTW, I committed an error here; Rei posted the reflexive DSCP policy draft Sunday night, but I had not seen that on Friday night, so I posted the same text in my draft just so we could have it on the agenda. We can decide as a working group whether we want to treat them together or separately, and whether we want to propose that policy. But there are two issues: how the sender views the traffic, and how the requester views it. I have been asked to build into my routers a facility to identify incoming requests, capture their DSCP, and ensure that answering streams use the same DSCP. My comment has invariably been that this is properly the province of the host, and most easily done there. But I am being pushed by those who don't trust the host to accomplish exactly this in the network. I would be much easier, from my perspective, if I could say "dimwit, the host already does this." And in Rei's case, the host may have specific policy embedded in metadata or some other policy mechanism that says it should use one service for this content and another service for that content. So we (Rei and I) propose that both of these are quite viable, and the one thing that is not really viable is to respond to a request sent with a very specific PHB with a default value. It would be better if the requester has the opportunity to influence the applied policy, and the responder (who may have metadata guiding him) has the ability to over-ride that. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 03:29:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06266 for ; Wed, 26 Jun 2002 03:29:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05165; Wed, 26 Jun 2002 03:27:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05131 for ; Wed, 26 Jun 2002 03:27:54 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06238 for ; Wed, 26 Jun 2002 03:27:08 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g5Q7RfD20495; Wed, 26 Jun 2002 08:27:41 +0100 From: "Alistair Munro" To: "'Fred Baker'" , "'Randy Bush'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Date: Wed, 26 Jun 2002 08:30:28 +0100 Message-ID: <000901c21ce3$590f6410$31281eac@degree2.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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <5.1.1.6.2.20020625163439.027b43f0@mira-sjcm-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, I support Fred's draft, apart from a few typos, and the tone of some of the text. It is not clear, from other comments, how it fits the charter, but this needs only a sentence to clarify. I have only general comments: Section 1.1 - says why you need to differentiate services but does not follow through the rationale for the emergency situation. Not sure about the first bullet "It has not always..." - true, but is it relevant, except as a comment on supply and demand? I would remove it. Last paragraph of 1.1 "The intent..." could move to become the last paragraph of the Introduction. Section 1.2 - the updates/clarifications to RFC2475 should be cited. I find the text useful to define the concepts used in section 2. It might be worth considering Section 1.3 - PHB is a key Diffserv term, although every hop has a behaviour, DiffServ or not. Move into 1.2? Define AF and EF, which are used without definition in 1.2.3. Section 2 - the table seems clear BCP. Direction on using DSCPs not mentioned in the table is also part of current practice and has a certain set of rules attached to it. Section 2.1 - RP -> RTP?, SIP -> SIP and/or H.320? Section 2.2 (and others) - is ECN part of DiffServ, is it BCP? Needs clarification (in 1.2.2?). Reference to [4] as "active queue management" - typo? Section 3 - as an implementer I don't have any issue with the policy and practice recommendations (apart from the usual problems of implementing policy). I don't think it's specific to IEPS, although IEPS has revealed it. There are many other issues hinted at in this section that illustrate the difficulties of deploying DiffServ, particularly global vs. local configuration. The report from the Internet2 Premium Service experiment: http://mail.internet2.edu:8080/guest/archives/qbone-arch-dt/log200205/ms g00000.html has some useful reference material. Section 4 - just say there are no security issues? Move first paragraph, apart from the last sentence, to the introductions. Move second paragraph in to section 3. I have some detailed text edits, but I'll pass these on paper at the meeting. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 03:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06753 for ; Wed, 26 Jun 2002 03:52:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06504; Wed, 26 Jun 2002 03:52:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06470 for ; Wed, 26 Jun 2002 03:52:33 -0400 (EDT) Received: from web20804.mail.yahoo.com (web20804.mail.yahoo.com [216.136.226.193]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06729 for ; Wed, 26 Jun 2002 03:51:48 -0400 (EDT) Message-ID: <20020626075232.50447.qmail@web20804.mail.yahoo.com> Received: from [134.193.6.40] by web20804.mail.yahoo.com via HTTP; Wed, 26 Jun 2002 00:52:32 PDT Date: Wed, 26 Jun 2002 00:52:32 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt To: Fred Baker Cc: ieprep@ietf.org In-Reply-To: <5.1.1.6.2.20020625234641.0272da30@mira-sjcm-4.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > So we (Rei and I) propose that both of these are > quite viable, and the one > thing that is not really viable is to respond to a > request sent with a very > specific PHB with a default value. It would be > better if the requester has > the opportunity to influence the applied policy, and > the responder (who may > have metadata guiding him) has the ability to > over-ride that. Another quick question: The requirement to have reflexive DSCP is only for emergency services or even for some other applications ? But,as i told ,consider a emergency information transfer between two persons.The reciver will surely know in priori the sender's priority .hence,receiver can use the same DSCP as the sender.There should be some other strong case for having a reflexive DSCP policy other than emergency application (Again,I am not sure ..i may be wrong) . - senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 04:04:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07160 for ; Wed, 26 Jun 2002 04:04:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08057; Wed, 26 Jun 2002 04:04:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08023 for ; Wed, 26 Jun 2002 04:04:35 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07122; Wed, 26 Jun 2002 04:03:44 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g5Q84OD21510; Wed, 26 Jun 2002 09:04:24 +0100 From: "Alistair Munro" To: , Cc: Subject: RE: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Date: Wed, 26 Jun 2002 09:07:11 +0100 Message-ID: <000a01c21ce8$79a2ad90$31281eac@degree2.com> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <200206251102.HAA29280@ietf.org> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, As an implementer, this draft raises more questions than it answers. I'm reluctant to accept it as current practice, (which it claims to be) although it is helpful in identifying the size of the solution space. I'm not sure if the attempt to use (subvert?) QoS differentiation and congestion management mechanisms to project application-level prioritisation to network level is a desirable thing to do, and it will end up being far too restrictive in practice. Maybe my interpretation is wrong on its intention, but I'm sure this has been deprecated in the past Having said this, the draft has given me a lot of ideas for experiments to identify potential best practice, but it's very speculative in its present form. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 05:13:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08515 for ; Wed, 26 Jun 2002 05:13:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11691; Wed, 26 Jun 2002 05:10:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11656 for ; Wed, 26 Jun 2002 05:10:41 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08433 for ; Wed, 26 Jun 2002 05:09:56 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-54.cisco.com [10.21.96.54]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5Q9A7L1018215; Wed, 26 Jun 2002 02:10:08 -0700 (PDT) Message-Id: <5.1.1.6.2.20020626020831.021c5bb8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 26 Jun 2002 02:10:05 -0700 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Cc: ieprep@ietf.org In-Reply-To: <20020626075232.50447.qmail@web20804.mail.yahoo.com> References: <5.1.1.6.2.20020625234641.0272da30@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:52 AM 6/26/2002 -0700, senthil ayyasamy wrote: >The reciver will surely >know in priori the sender's priority .hence,receiver >can use the same DSCP as the sender. why would a DSCP necessarily indicate a priority? Apart from an authenticated user transaction, why would the sender know what the receiver those a policy should be? The question becomes: if I have several users with different contracts asking me about file foo, why would I not deliver file foo in accordance with their several contracts? >There should be >some other strong case for having a reflexive DSCP >policy other than emergency application the places I am being pushed for it are in general use. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 05:38:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08870 for ; Wed, 26 Jun 2002 05:38:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12914; Wed, 26 Jun 2002 05:37:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12883 for ; Wed, 26 Jun 2002 05:37:08 -0400 (EDT) Received: from web20803.mail.yahoo.com (web20803.mail.yahoo.com [216.136.226.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08845 for ; Wed, 26 Jun 2002 05:36:23 -0400 (EDT) Message-ID: <20020626093707.33512.qmail@web20803.mail.yahoo.com> Received: from [134.193.6.40] by web20803.mail.yahoo.com via HTTP; Wed, 26 Jun 2002 02:37:07 PDT Date: Wed, 26 Jun 2002 02:37:07 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt To: Fred Baker Cc: ieprep@ietf.org In-Reply-To: <5.1.1.6.2.20020626020831.021c5bb8@mira-sjcm-4.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > >The reciver will surely > >know in priori the sender's priority > .hence,receiver > >can use the same DSCP as the sender. > > why would a DSCP necessarily indicate a priority? > Apart from an > authenticated user transaction, why would the sender > know what the receiver > those a policy should be? If i understood clearly,Your intent is to have have different/Same DSCP mapping at both directions depending on one's requirements or policy.Considering X and Y as sender and receiver,DSCP used from X-->Y and Y-->X can be different. I misunderstood that the whole work is *ONLY* to maintain same DSCP on both directions. ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 06:45:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11225 for ; Wed, 26 Jun 2002 06:45:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17454; Wed, 26 Jun 2002 06:44:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17419 for ; Wed, 26 Jun 2002 06:44:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11069; Wed, 26 Jun 2002 06:43:51 -0400 (EDT) Message-Id: <200206261043.GAA11069@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: Wed, 26 Jun 2002 06:43:50 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-reflexive-dscp-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Diffserv Reflexive DSCP Author(s) : R. Atarashi, F. Baker Filename : draft-ietf-ieprep-reflexive-dscp-00.txt Pages : 9 Date : 25-Jun-02 In reviewing the specific use of the Differentiated Services Architecture for supporting the Internet Emergency Preparedness System, we found what we believe is a general issue. This is that even though a client or peer can connect to a server or peer with a predictable DSCP value, the response does not have a predictable DSCP value. We consider the issues, and recommend an approach to application policy regarding the DSCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-reflexive-dscp-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-reflexive-dscp-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-reflexive-dscp-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: <20020625142241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-reflexive-dscp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-reflexive-dscp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625142241.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 11:16:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22766 for ; Wed, 26 Jun 2002 11:16:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05341; Wed, 26 Jun 2002 11:15:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05312 for ; Wed, 26 Jun 2002 11:15:49 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22598 for ; Wed, 26 Jun 2002 11:15:04 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-409.cisco.com [10.21.65.153]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5QFF6L1003759; Wed, 26 Jun 2002 08:15:07 -0700 (PDT) Message-Id: <5.1.1.6.2.20020626081136.04bc3ea0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 26 Jun 2002 08:15:02 -0700 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt Cc: ieprep@ietf.org In-Reply-To: <20020626093707.33512.qmail@web20803.mail.yahoo.com> References: <5.1.1.6.2.20020626020831.021c5bb8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 02:37 AM 6/26/2002 -0700, senthil ayyasamy wrote: >DSCP used from X-->Y >and Y-->X can be different. they certainly can, and right now usually are. But service providers deploying diffserv tell me that this is not necessarily the service they want to offer. They want to be able to offer varying grades of service to users paying varying amounts of money. > I misunderstood that the whole work is *ONLY* to >maintain same DSCP on both directions. yes, and also to say what that DSCP is based on some concept of user class. If, for example, I have a user class which is "authenticated ETS user" and another user class which is "random person", the traffic in the first class might go as AF11 and the second as AF12 (same queue, slightly more prone to loss). not that this would be important in a group such as this :^) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 11:22:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23056 for ; Wed, 26 Jun 2002 11:22:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05587; Wed, 26 Jun 2002 11:22:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05561 for ; Wed, 26 Jun 2002 11:22:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23004 for ; Wed, 26 Jun 2002 11:21:12 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-409.cisco.com [10.21.65.153]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5QFLIL1007056; Wed, 26 Jun 2002 08:21:19 -0700 (PDT) Message-Id: <5.1.1.6.2.20020626081525.04ca33a8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 26 Jun 2002 08:21:15 -0700 To: "Alistair Munro" From: Fred Baker Subject: RE: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Cc: In-Reply-To: <000a01c21ce8$79a2ad90$31281eac@degree2.com> References: <200206251102.HAA29280@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 09:07 AM 6/26/2002 +0100, Alistair Munro wrote: >As an implementer, this draft raises more questions than it answers. I'm >reluctant to accept it as current practice, (which it claims to be) There you have only my claim to follow. We have been putting the list together at Cisco based on an accumulation of networks and products (ours and others) using various DSCP values with various application sets. The scavenger service is an Internet II service, for example, one that doesn't make much sense to me (I thought that was what the default service was for) but which a lot of folks are fairly excited about (they pay less money for transfer with no guarantees). >I'm not sure if the attempt to use (subvert?) QoS differentiation and >congestion management mechanisms to project application-level >prioritisation to network level is a desirable thing to do, and it will >end up being far too restrictive in practice. Maybe my interpretation is >wrong on its intention, but I'm sure this has been deprecated in the past speaking as one of the folks who designed the differentiaed services architecture, I assure you that this is fundamental to diffserv. You take traffic that has similar requirements and is going to similar user groups and handle it as an aggregate. The facilities you enable for the traffic in a certain aggregate are intended to be consistent with the needs of the applications in that aggregate. Why are you sending a working group discussion to ietf-announce? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 11:41:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24576 for ; Wed, 26 Jun 2002 11:41:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06778; Wed, 26 Jun 2002 11:37:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06698 for ; Wed, 26 Jun 2002 11:37:22 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24015 for ; Wed, 26 Jun 2002 11:36:37 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g5QFb6D00535; Wed, 26 Jun 2002 16:37:06 +0100 From: "Alistair Munro" To: "'Fred Baker'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Date: Wed, 26 Jun 2002 16:39:54 +0100 Message-ID: <004001c21d27$b79a54b0$31281eac@degree2.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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <5.1.1.6.2.20020626081525.04ca33a8@mira-sjcm-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > >As an implementer, this draft raises more questions than it answers. > >I'm > >reluctant to accept it as current practice, (which it claims to be) > > There you have only my claim to follow. We have been putting the list > together at Cisco based on an accumulation of networks and > products (ours > and others) using various DSCP values with various > application sets. The > scavenger service is an Internet II service, for example, one > that doesn't > make much sense to me (I thought that was what the default > service was for) > but which a lot of folks are fairly excited about (they pay > less money for > transfer with no guarantees). > Are we talking about the same draft? I agree with what you say in yours, but I was referring to the Talauliker one in this case. The stuff about RED (and variants) appears to be simulations, hence my comment about more questions than answers as far as practice goes, but please correct me. > >I'm not sure if the attempt to use (subvert?) QoS differentiation and > >congestion management mechanisms to project application-level > >prioritisation to network level is a desirable thing to do, > and it will > >end up being far too restrictive in practice. Maybe my > interpretation is > >wrong on its intention, but I'm sure this has been > deprecated in the past > > speaking as one of the folks who designed the differentiaed services > architecture, I assure you that this is fundamental to > diffserv. You take > traffic that has similar requirements and is going to similar > user groups > and handle it as an aggregate. The facilities you enable for > the traffic in > a certain aggregate are intended to be consistent with the > needs of the > applications in that aggregate. > I'm not questioning this either. It is the issue of priority vs. quality that concerned me. The Talauliker draft seems to be about priority using DSCPs and RED mechanisms. I would prefer to use them to their best advantage in doing what they were designed for without imposing a secondary purpose on them. Priority is a different issue and known to be difficult to resolve. Did I mistake what was written? > Why are you sending a working group discussion to ietf-announce? I'm sorry about this - I didn't delete the ietf-announce in the reply. It was not intentional. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jun 26 12:29:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27641 for ; Wed, 26 Jun 2002 12:29:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12266; Wed, 26 Jun 2002 12:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12230 for ; Wed, 26 Jun 2002 12:28:49 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27573 for ; Wed, 26 Jun 2002 12:28:05 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-409.cisco.com [10.21.65.153]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5QGS9L1015480; Wed, 26 Jun 2002 09:28:10 -0700 (PDT) Message-Id: <5.1.1.6.2.20020626092733.021445c8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 26 Jun 2002 09:28:05 -0700 To: "Alistair Munro" From: Fred Baker Subject: RE: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Cc: In-Reply-To: <004001c21d27$b79a54b0$31281eac@degree2.com> References: <5.1.1.6.2.20020626081525.04ca33a8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:39 PM 6/26/2002 +0100, Alistair Munro wrote: >Are we talking about the same draft? I agree with what you say in yours, >but I was referring to the Talauliker one in this case. I'm sorry, I should have read your subject line less quickly. oops. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jun 27 06:42:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09917 for ; Thu, 27 Jun 2002 06:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20545; Thu, 27 Jun 2002 06:42:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20511 for ; Thu, 27 Jun 2002 06:42:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09730; Thu, 27 Jun 2002 06:41:41 -0400 (EDT) Message-Id: <200206271041.GAA09730@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, 27 Jun 2002 06:41:41 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. 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-02.txt Pages : 30 Date : 26-Jun-02 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 International Emergency Preparedness Scheme (IEPS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of functional requirements, 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-02.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-02.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-02.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: <20020626135229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135229.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jun 27 12:44:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00378 for ; Thu, 27 Jun 2002 12:44:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24923; Thu, 27 Jun 2002 12:38:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24888 for ; Thu, 27 Jun 2002 12:38:43 -0400 (EDT) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00063 for ; Thu, 27 Jun 2002 12:37:59 -0400 (EDT) Message-ID: <20020627163840.80953.qmail@web20805.mail.yahoo.com> Received: from [134.193.27.2] by web20805.mail.yahoo.com via HTTP; Thu, 27 Jun 2002 09:38:40 PDT Date: Thu, 27 Jun 2002 09:38:40 -0700 (PDT) From: senthil ayyasamy To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] Fwd: I-D ACTION:draft-ayyasamy-ieprep-isp-recommend-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org FYI --- Internet-Drafts@ietf.org wrote: > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Subject: I-D > ACTION:draft-ayyasamy-ieprep-isp-recommend-00.txt > Date: Thu, 27 Jun 2002 06:40:23 -0400 > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Recommended Internet Service Provider > Procedures For > Emergency Preparedness > Author(s) : S. Ayyasamy, F. Baker > Filename : > draft-ayyasamy-ieprep-isp-recommend-00.txt > Pages : 15 > Date : 26-Jun-02 > > The purpose of this document is to express what the > engineering > community expects of Service providers with respect > to emergency > preparedness. The document can be considered as a > set of > recommendations to support mission-critical traffic > at various > locations like access and core. > The goal of the draft is to raise discussion among > Internet service > providers (ISPs) on the importance of accommodating > emergency > services across Internet. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ayyasamy-ieprep-isp-recommend-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-ayyasamy-ieprep-isp-recommend-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-ayyasamy-ieprep-isp-recommend-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. > ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 04:20:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14121 for ; Fri, 28 Jun 2002 04:20:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03828; Fri, 28 Jun 2002 04:20:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03795 for ; Fri, 28 Jun 2002 04:20:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14114 for ; Fri, 28 Jun 2002 04:19:43 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5S8JvL1027214 for ; Fri, 28 Jun 2002 01:19:57 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628011824.026e8c08@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 01:19:56 -0700 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Reasoning behind agenda Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Here are the documents that I see posted for discussion in Yokohama. I have asked for two slots, a total of 4 hours, and we'll see where that goes. draft-ietf-ieprep-security-00.txt draft-ietf-ieprep-requirements-00.txt draft-carlberg-ieprep-elastic-requirements-00.txt draft-ietf-ieprep-packet-marking-policy-00.txt draft-ietf-ieprep-reflexive-dscp-00.txt draft-ietf-ieprep-framework-02.txt I'm not sure what the intersection of talauliker and baker's drafts are; from my perspective, it sounds like a submission to diffserv more than a submission to ieprep. We'll discuss it given time, and see what we want to do with it. I note that diffserv didn't choose to standardize the RIO mechanism, or Cisco's WRED mechanism, or Lucent's approach, or the approach recommended by Van and Kathy called RED-Lite, or any of a list of others. Diffserv rather chose to identify AQM mechanisms as a class of equally acceptable algorithms. I also note that there is little substantive difference between what this proposes and an AF service which treats all emergency traffic as AFn1 traffic. draft-talauliker-ieprep-diffserv-00.txt This draft was discussed somewhat at the interim meeting, and on the list. Scott, Allison, and I have been thinking about the approach, and Scott has a proposal for what he believes may be a better approach, embedding the policy lookup in the RSVP exchange. I believe that we will have a joint meeting with the SIP folks to sort this out. draft-schulzrinne-ieprep-resource-req-00.txt This draft is not, strictly speaking, in our charter, but may represent a direction for further work in this area. We may discuss it if we have time. draft-ayyasamy-ieprep-isp-recommend-00.txt There are also a few documents laying around that we discussed at the interim meeting, and have since been merged. They are not current. By "discuss", I mean just that - I am expecting no presentations at this meeting per se, but rather for the document authors to lead a discussion of their draft looking for holes and general sign-off. There is at least one document that didn't make the draft cutoff - Ian's contract terminology document. My sense is that this will be important enough to simply finish on the list or delay to the fall IETF meeting in Atlanta. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 05:23:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15479 for ; Fri, 28 Jun 2002 05:23:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03963; Fri, 28 Jun 2002 04:22:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03933 for ; Fri, 28 Jun 2002 04:22:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14157; Fri, 28 Jun 2002 04:21:47 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5S8LuL1027712; Fri, 28 Jun 2002 01:21:56 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628012009.00a41e18@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 01:21:55 -0700 To: ieprep@ietf.org From: Fred Baker Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Yokohama IEPREP meeting agenda Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Per the agenda at http://www.ietf.org/meetings/agenda_54.html, we have two slots, at 1530 on Wednesday and 1530 on Thursday. I propose that we plan to spend them so: Wednesday: agenda bashing 10 minutes draft-ietf-ieprep-security-00.txt 30 minutes draft-ietf-ieprep-requirements-00.txt 30 minutes draft-carlberg-ieprep-elastic-requirements-00.txt 30 minutes Thursday: draft-ietf-ieprep-packet-marking-policy-00.txt 30 minutes draft-ietf-ieprep-reflexive-dscp-00.txt 15 minutes draft-ietf-ieprep-framework-02.txt 30 minutes discussion of what should be in the T&C draft 30 minutes Depending on how timing goes (discussions might wax long or short, and both days have some planned slop in them) we are likely to get into these drafts draft-talauliker-ieprep-diffserv-00.txt draft-ayyasamy-ieprep-isp-recommend-00.txt By "discuss", I mean just that - I am expecting no presentations at this meeting per se, but rather for the document authors to lead a discussion of their draft looking for holes and general sign-off. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 07:52:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21289 for ; Fri, 28 Jun 2002 07:52:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18726; Fri, 28 Jun 2002 07:50:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18694 for ; Fri, 28 Jun 2002 07:50:42 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21166 for ; Fri, 28 Jun 2002 07:49:56 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jun 2002 12:50:19 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Fred Baker cc: ieprep@ietf.org Subject: Re: [Ieprep] Reasoning behind agenda In-reply-to: Your message of "Fri, 28 Jun 2002 01:19:56 PDT." <5.1.1.6.2.20020628011824.026e8c08@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 12:50:16 +0100 Message-ID: <846.1025265016@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > This draft was discussed somewhat at the interim meeting, and on the > list. Scott, Allison, and I have been thinking about the approach, and > Scott has a proposal for what he believes may be a better approach, > embedding the policy lookup in the RSVP exchange. I believe that we will > have a joint meeting with the SIP folks to sort this out. > > draft-schulzrinne-ieprep-resource-req-00.txt will the draft be presented at the joint meeting, or not at all? I noticed that there wasn't an IEPREP time slot set aside for the draft. or is the draft sort of dead on arrival given Scott's new proposal? -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 11:00:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29690 for ; Fri, 28 Jun 2002 11:00:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00800; Fri, 28 Jun 2002 10:59:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00766 for ; Fri, 28 Jun 2002 10:59:40 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29632 for ; Fri, 28 Jun 2002 10:58:52 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SEx4L1007444; Fri, 28 Jun 2002 07:59:04 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628075819.04428188@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 07:59:02 -0700 To: Ken Carlberg From: Fred Baker Subject: Re: [Ieprep] Reasoning behind agenda Cc: ieprep@ietf.org In-Reply-To: <846.1025265016@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:50 PM 6/28/2002 +0100, Ken Carlberg wrote: >will the draft be presented at the joint meeting, or not at all? >I noticed that there wasn't an IEPREP time slot set aside for the >draft. or is the draft sort of dead on arrival given Scott's new >proposal? I thought we had already more or less discussed it; we can certainly continue that discussion. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 11:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29773 for ; Fri, 28 Jun 2002 11:01:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01417; Fri, 28 Jun 2002 11:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01381 for ; Fri, 28 Jun 2002 11:01:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29739; Fri, 28 Jun 2002 11:01:04 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SF1JL1009582; Fri, 28 Jun 2002 08:01:19 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628075921.04414e20@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 08:01:16 -0700 To: ieprep@ietf.org From: Fred Baker Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Revised Yokohama IEPREP meeting agenda Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Per the agenda at http://www.ietf.org/meetings/agenda_54.html, we have two slots, at 1530 on Wednesday and 1530 on Thursday. I propose that we plan to spend them so: Wednesday: agenda bashing 10 minutes draft-ietf-ieprep-security-00.txt 30 minutes draft-ietf-ieprep-requirements-00.txt 30 minutes draft-carlberg-ieprep-elastic-requirements-00.txt 30 minutes Thursday: draft-ietf-ieprep-packet-marking-policy-00.txt 30 minutes draft-ietf-ieprep-reflexive-dscp-00.txt 15 minutes draft-ietf-ieprep-framework-02.txt 30 minutes draft-schulzrinne-ieprep-resource-req-00.txt 30 minutes T&C Draft directions 15 minutes Depending on how timing goes we are likely to get into these drafts draft-talauliker-ieprep-diffserv-00.txt draft-ayyasamy-ieprep-isp-recommend-00.txt By "discuss", I mean just that - I am expecting no presentations at this meeting per se, but rather for the document authors to lead a discussion of their draft looking for holes and general sign-off. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 11:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00618 for ; Fri, 28 Jun 2002 11:21:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02080; Fri, 28 Jun 2002 11:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02043 for ; Fri, 28 Jun 2002 11:21:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00589; Fri, 28 Jun 2002 11:21:06 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SFLLL1020437; Fri, 28 Jun 2002 08:21:21 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628081532.0474ab80@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 08:21:19 -0700 To: ieprep@ietf.org, agenda@ietf.org From: Fred Baker In-Reply-To: <5.1.1.6.2.20020628075921.04414e20@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Revised Yokohama IEPREP meeting agenda Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 08:01 AM 6/28/2002 -0700, Fred Baker wrote: Per the agenda at http://www.ietf.org/meetings/agenda_54.html, we have two slots, at 1530 on Wednesday and 1530 on Thursday. I propose that we plan to spend them so: Wednesday: agenda bashing 10 minutes AD Discussion 15 minutes draft-ietf-ieprep-security-00.txt 30 minutes draft-ietf-ieprep-requirements-00.txt 30 minutes draft-carlberg-ieprep-elastic-requirements-00.txt 30 minutes Thursday: draft-ietf-ieprep-packet-marking-policy-00.txt 30 minutes draft-ietf-ieprep-reflexive-dscp-00.txt 15 minutes draft-ietf-ieprep-framework-02.txt 30 minutes draft-schulzrinne-ieprep-resource-req-00.txt 30 minutes T&C Draft directions 15 minutes Depending on how timing goes we may get into these drafts draft-talauliker-ieprep-diffserv-00.txt draft-ayyasamy-ieprep-isp-recommend-00.txt By "discuss", I mean just that - I am expecting no presentations at this meeting per se, but rather for the document authors to lead a discussion of their draft looking for holes and general sign-off. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 11:41:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01628 for ; Fri, 28 Jun 2002 11:41:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03208; Fri, 28 Jun 2002 11:42:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03178 for ; Fri, 28 Jun 2002 11:42:25 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01617 for ; Fri, 28 Jun 2002 11:41:37 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SFfqL1002131 for ; Fri, 28 Jun 2002 08:41:52 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628082902.046c5a38@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 08:41:50 -0700 To: ieprep@ietf.org From: Fred Baker In-Reply-To: <5.1.1.6.2.20020628075921.04414e20@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Detailed comments Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org By the way, if you have detailed comments on drafts, you can correspond privately with the author for detail level stuff, or post them to the list for more general discussion, as you deem appropriate. In the case of my marking draft, for example, I have received private commentary from Kimberly and Alistair, improving my english and pointing out details I had missed. An updated version is at ftp://ftpeng.cisco.com/fred/ieprep/Marking.html or ftp://ftpeng.cisco.com/fred/ieprep/Marking.txt, from which I will post it after the IETF meeting. I'd encourage everyone to read the drafts (this is a plea - these drafts are hopefully substantively the working group output, so let's make sure they're correct), and if they have questions or concerns about any of them post comments to the list. That both frees the meeting time to focus on remaining issues and ensures that your comments get correctly into the record in detail. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 15:27:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16335 for ; Fri, 28 Jun 2002 15:27:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25034; Fri, 28 Jun 2002 15:27:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24771 for ; Fri, 28 Jun 2002 15:23:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16168 for ; Fri, 28 Jun 2002 15:22:42 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5SJMpLH021476; Fri, 28 Jun 2002 12:22:51 -0700 (PDT) Received: from open-131-161-248-86.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAI60551; Fri, 28 Jun 2002 12:22:48 -0700 (PDT) Date: Fri, 28 Jun 2002 12:23:10 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-6--259649681 Mime-Version: 1.0 (Apple Message framework v482) Cc: rohan@cisco.com, hgs@cs.columbia.edu To: ieprep@ietf.org From: Rohan Mahy Message-Id: <7B97EE5E-8ACC-11D6-BA11-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.482) Subject: [Ieprep] comments on draft-schulzrinne-ieprep-resource-req Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --Apple-Mail-6--259649681 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, A few comments.... - If this becomes a working group document, I think draft-ietf-ieprep-sip-reqs would be a more relevant filename. (IEPREP requirements for SIP) - from the Introduction > 3. Resources in networks may be managed based on SIP calls. > (This is not always desirable or feasible due to the > divergence of media and signaling paths and the limited > ability of session setup messages to express traffic > characteristics, but it may be the only available mechanism > absent a resource reservation protocol.) In such cases, > policy may grant emergency preparedness or MLPP calls > prioritized access. > > 4. In some circumstances, it may be appropriate to prioritize > access to signaling resources (e.g., CPU cycles) in SIP > proxies. I'm not convinced that 4) is required or even technically possible for a proxy to give prioritized access to one SIP request over another. Most of the work is already done by the time you could know the request has a higher priority. Of course you can just send a "Server Unavailable response" to non-priority requests, but it is unclear that this reduces load significantly. -Also, I think that the requirement implied in number 3 is cumbersome and poorly stated. what is the requirement here? is this a requirement that session setup via SIP may need appropriate QoS marked or requested? if it is, say so directly. - I think there is a requirement missing, in that some emergency service domains want to preempt or indicate relative priorities for native SIP endpoints (for example, priority of a queue operated by a hospital operator, preemption of "focus" on a user-oriented endpoint, or preemption of resources on a media mixer or conference server). This could potentially use the same mechanism as 1). > Thus, it is conceivable that the system indication can sometimes cause > preemption, while otherwise it just - near the end of section 1, this sentence ends abruptly > 2 Relationship to Emergency Call Services > > The resource priority mechanisms are used to have selected > individuals place calls with elevated priority during times when the > network is suffering from an emergency-induced shortage of resources. > Generally, calls for emergency help placed by non-officials (e.g., > "911" and "112" calls) don't need resource priority under normal > circumstances. If such emergency calls are placed during emergency- > induced network resource shortages, the call identifier itself is > sufficient to identify the emergency nature of the call. Adding an > indication of resource priority may be less appropriate, as this > would require that all such calls carry this indicator. Also, it > opens another attack mechanism, where non-emergency calls are marked > as emergency calls. (If the entity can recognize the request URI as > an emergency call, it would not need the resource priority > mechanism.) - perhaps there is a requirement to create an "ordinary emergency services" class of priority? I don't have a strong feeling about this, but it seems reasonable. - the security requirements are WAY underspecified. thanks, -rohan mahy (SIPPING co-chair) --Apple-Mail-6--259649681 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, A few comments.... - If this becomes a working group document, I think draft-ietf-ieprep-sip-reqs would be a more relevant filename. (IEPREP requirements for SIP) - from the IntroductionCourier New Arial 3. Resources in networks may be managed based on SIP calls. (This is not always desirable or feasible due to the divergence of media and signaling paths and the limited ability of session setup messages to express traffic characteristics, but it may be the only available mechanism absent a resource reservation protocol.) In such cases, policy may grant emergency preparedness or MLPP calls prioritized access. 4. In some circumstances, it may be appropriate to prioritize access to signaling resources (e.g., CPU cycles) in SIP proxies. I'm not convinced that 4) is required or even technically possible for a proxy to give prioritized access to one SIP request over another. Most of the work is already done by the time you could know the request has a higher priority. Of course you can just send a "Server Unavailable response" to non-priority requests, but it is unclear that this reduces load significantly. -Also, I think that the requirement implied in number 3 is cumbersome and poorly stated. what is the requirement here? is this a requirement that session setup via SIP may need appropriate QoS marked or requested? if it is, say so directly. - I think there is a requirement missing, in that some emergency service domains want to preempt or indicate relative priorities for native SIP endpoints (for example, priority of a queue operated by a hospital operator, preemption of "focus" on a user-oriented endpoint, or preemption of resources on a media mixer or conference server). This could potentially use the same mechanism as 1). ArialThus, it is conceivable that the system indication can sometimes cause preemption, while otherwise it just - near the end of section 1, this sentence ends abruptly Arial2 Relationship to Emergency Call Services The resource priority mechanisms are used to have selected individuals place calls with elevated priority during times when the network is suffering from an emergency-induced shortage of resources. Generally, calls for emergency help placed by non-officials (e.g., "911" and "112" calls) don't need resource priority under normal circumstances. If such emergency calls are placed during emergency- induced network resource shortages, the call identifier itself is sufficient to identify the emergency nature of the call. Adding an indication of resource priority may be less appropriate, as this would require that all such calls carry this indicator. Also, it opens another attack mechanism, where non-emergency calls are marked as emergency calls. (If the entity can recognize the request URI as an emergency call, it would not need the resource priority mechanism.) - perhaps there is a requirement to create an "ordinary emergency services" class of priority? I don't have a strong feeling about this, but it seems reasonable. - the security requirements are WAY underspecified. thanks, -rohan mahy (SIPPING co-chair) --Apple-Mail-6--259649681-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 15:32:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16668 for ; Fri, 28 Jun 2002 15:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25158; Fri, 28 Jun 2002 15:29:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25120 for ; Fri, 28 Jun 2002 15:29:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16432; Fri, 28 Jun 2002 15:28:13 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-sb1-184-201.cisco.com [171.69.184.201]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SJSML1011854; Fri, 28 Jun 2002 12:28:22 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628122800.025ada68@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 12:28:20 -0700 To: Dinara Suleymanova From: Fred Baker Cc: agenda@ietf.org, Scott Bradner , Allison Mankin , Steve Coya , Marcia Beaulieu , ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020628151117.04861560@odin> References: <5.1.1.6.2.20020628095005.042dddb8@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Re: MBONE in ieprep sessions Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 03:15 PM 6/28/2002 -0400, Dinara Suleymanova wrote: >It's impossible for the first session which is on Wednesday to have >MULTICAST (mbone) >but your second session on Thursday is now in the MULTICAST room. >So you have one multicast session. This is all we could do. OK, thanks. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 15:48:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17720 for ; Fri, 28 Jun 2002 15:48:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26488; Fri, 28 Jun 2002 15:48:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26452 for ; Fri, 28 Jun 2002 15:48:12 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17622 for ; Fri, 28 Jun 2002 15:47:25 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id A78A767103 for ; Fri, 28 Jun 2002 16:24:45 -0400 (EDT) Date: Fri, 28 Jun 2002 15:47:23 -0400 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Ieprep] ieprep/Marking.html Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Fred, It seems to me that an API that might affect the DSCP used for traffic (or other QoS parameters) ought to require that only processes with "appropriate privilege" be able to use that API to modify their DSCP value from whatever the system default DSCP value might be. I think this means some additional text here and there in Section 3 and also in Section 4 of the above draft. If you think I'm confused, please help me understand how I'm confused. Thanks, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 16:07:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18887 for ; Fri, 28 Jun 2002 16:07:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28081; Fri, 28 Jun 2002 16:07:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28050 for ; Fri, 28 Jun 2002 16:07:26 -0400 (EDT) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18829; Fri, 28 Jun 2002 16:06:39 -0400 (EDT) Received: from [63.105.122.236] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1386791; Fri, 28 Jun 2002 16:07:23 -0400 Message-ID: <3D1CC1EB.5080005@multicasttech.com> Date: Fri, 28 Jun 2002 16:07:07 -0400 From: Marshall Eubanks User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Fred Baker CC: Dinara Suleymanova , agenda@ietf.org, Scott Bradner , Allison Mankin , Steve Coya , Marcia Beaulieu , ieprep@ietf.org, tech@multicasttech.com Subject: Re: [Ieprep] Re: MBONE in ieprep sessions References: <5.1.1.6.2.20020628095005.042dddb8@mira-sjcm-4.cisco.com> <5.1.1.6.2.20020628122800.025ada68@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Fred; This is literally the first I have heard of this; but if you have the bandwidth and a video feed, we can make the multicasts happen. It would be convenient if this was in the DC area... Regards Marshall Eubanks Fred Baker wrote: > At 03:15 PM 6/28/2002 -0400, Dinara Suleymanova wrote: > >> It's impossible for the first session which is on Wednesday to have >> MULTICAST (mbone) >> but your second session on Thursday is now in the MULTICAST room. >> So you have one multicast session. This is all we could do. > > > OK, thanks. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 16:40:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20606 for ; Fri, 28 Jun 2002 16:40:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00421; Fri, 28 Jun 2002 16:39:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00384 for ; Fri, 28 Jun 2002 16:39:05 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20493 for ; Fri, 28 Jun 2002 16:38:18 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 8AB6167103 for ; Fri, 28 Jun 2002 17:15:48 -0400 (EDT) Date: Fri, 28 Jun 2002 16:38:33 -0400 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit Message-Id: <036A0EB7-8AD7-11D6-AA41-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit An underlying issue with this document is the assumption that backbones might be under-provisioned. Many large backbones are in fact over-provisioned. That is, they have more capacity than they have maximum potential offered load. In many cases, this capacity is built on multiple wide-area SONET rings, so that even an earthquake or smallish tactical nuclear bombs would not cause them to be underprovisioned.[1] In such a network, QoS is not really a meaningful concept. It seems to me that an operator with such a network might well be able to provide the services desired for IEPREP without making any special provisions in their network (other than ensuring robust overprovisioning continues to be the case). That possibility is not reflected in this draft and seems like a major omission to me. Ran rja@extremenetworks.com [1] To be clear, most congestion and packet loss today occurs in the access portion of the Internet, which is often operated by a smaller Tier-2/3/4 provider different from the Tier-1 transit/backbone operator. In this situation, QoS might be useful inside the Tier-N operator (e.g. on particular access links that aren't overprovisioned by the Tier-N operator), but QoS would likely not be meaningful inside the Tier-1 backbone. [2] Experience to date is that the Internet has not suffered from extreme traffic loads (i.e. more than the Internet can handle) even in the presence of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th). In fact, during such situations the "best effort" Internet has continued to work quite well, thanks to a robust Internet Architecture. This fact is also not reflected in the above draft -- and seems like a bug. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 16:54:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21419 for ; Fri, 28 Jun 2002 16:54:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01345; Fri, 28 Jun 2002 16:54:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01308 for ; Fri, 28 Jun 2002 16:54:18 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21269 for ; Fri, 28 Jun 2002 16:53:31 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 16:52:52 -0400 Message-ID: From: "Gunn, Janet NE" To: "'RJ Atkinson'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Fri, 28 Jun 2002 16:52:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org While we have (luckily) not yet experienced it, it is quite possible to imagine an emergency that causes a significant reduction in backbone capacity. We should be prepared to address that. But I agree that congestion/ lack of adequate provisioning at the "edges" is a more probable case. Janet -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Friday, June 28, 2002 4:39 PM To: ieprep Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt ... [2] Experience to date is that the Internet has not suffered from extreme traffic loads (i.e. more than the Internet can handle) even in the presence of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th). In fact, during such situations the "best effort" Internet has continued to work quite well, thanks to a robust Internet Architecture. This fact is also not reflected in the above draft -- and seems like a bug. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 17:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22464 for ; Fri, 28 Jun 2002 17:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03143; Fri, 28 Jun 2002 17:10:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03106 for ; Fri, 28 Jun 2002 17:10:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22189 for ; Fri, 28 Jun 2002 17:09:27 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SL9ROI001791; Fri, 28 Jun 2002 14:09:27 -0700 (PDT) Received: from SKEAGY-W2K1.cisco.com (sjc-vpn3-873.cisco.com [10.21.67.105]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA01154; Fri, 28 Jun 2002 14:09:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20020628135758.02887f08@malone.cisco.com> X-Sender: skeagy@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jun 2002 14:09:25 -0700 To: "Gunn, Janet NE" , "'RJ Atkinson'" , ieprep From: Scott Keagy Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Specifically consider the possibility that Internet choke points could be the target of unfriendly activities, which was not the case in other disasters previously mentioned where the net performed well. How much damage would result from the removal of 5-10 well chosen NAPs? Seems that the economic impact of this would be an attractive target. Also consider all CO's being targeted in a given metro area, so physical facilities are gone for a large region. This would take out landlines and wireless networks that connect through the COs. Not really in scope for ieprep but should be thought about somewhere... mobile ad-hoc networks? Long term, this is an aspect of internet emergency preparedness. -Scott At 04:52 PM 6/28/2002 -0400, Gunn, Janet NE wrote: >While we have (luckily) not yet experienced it, it is quite possible to >imagine an emergency that causes a significant reduction in backbone >capacity. We should be prepared to address that. But I agree that >congestion/ lack of adequate provisioning at the "edges" is a more probable >case. > >Janet > >-----Original Message----- >From: RJ Atkinson [mailto:rja@extremenetworks.com] >Sent: Friday, June 28, 2002 4:39 PM >To: ieprep >Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > >... > >[2] Experience to date is that the Internet has not suffered from extreme >traffic loads (i.e. more than the Internet can handle) even in the >presence >of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th). >In fact, during such situations the "best effort" Internet has continued >to work quite well, thanks to a robust Internet Architecture. This fact >is also not reflected in the above draft -- and seems like a bug. > > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 17:20:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22934 for ; Fri, 28 Jun 2002 17:20:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03944; Fri, 28 Jun 2002 17:20:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03911 for ; Fri, 28 Jun 2002 17:20:37 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22919 for ; Fri, 28 Jun 2002 17:19:50 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id E9ACA67103; Fri, 28 Jun 2002 17:57:20 -0400 (EDT) Date: Fri, 28 Jun 2002 17:20:05 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: Scott Keagy From: RJ Atkinson In-Reply-To: <4.3.2.7.2.20020628135758.02887f08@malone.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 05:09 , Scott Keagy wrote: > How much damage would result from the removal of 5-10 well chosen NAPs? QoS in the core still would not be relevant. That's an argument for QoS at the edge, which I specifically noted might be useful in *some* situations. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 17:33:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23654 for ; Fri, 28 Jun 2002 17:33:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04526; Fri, 28 Jun 2002 17:30:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04472 for ; Fri, 28 Jun 2002 17:30:27 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23386 for ; Fri, 28 Jun 2002 17:29:38 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 6BDE567103; Fri, 28 Jun 2002 18:07:09 -0400 (EDT) Date: Fri, 28 Jun 2002 17:29:53 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: "Gunn, Janet NE" From: RJ Atkinson In-Reply-To: Message-Id: <2F97711F-8ADE-11D6-AA41-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 04:52 , Gunn, Janet NE wrote: > While we have (luckily) not yet experienced it, it is quite possible to > imagine an emergency that causes a significant reduction in backbone > capacity. In a lot of cases so far lack of problems has not been luck, but rather thoughtful planning for robustness and for overprovisioning by backbone operators. For several large ISP networks that I either worked on or am very familiar with, it is pretty hard to imagine any emergency or disaster that would cause a significant reduction in backbone capacity -- because they've been very careful in their buildout to use diverse physical paths, redundant SONET rings in the WAN, and various other techniques -- unless the situation were so dire that all capacity were gone in that region. To take some of them out, one has to take out the entire communications infrastructure of a geographic region -- at which point QoS still doesn't help because there is zero capacity in that region. The point I'm making here is that QoS is a *mechanism* that might be useful in a number of situations. It is not useful in *every* situation. The requirements need to reflect that. The real requirement is availability when desired, not which method the provider employs to cause that availability to happen. So far, many ISPs have done the business analysis and concluded that it is more cost-effective to over-engineer their networks (with redundancy, capacity, and in other dimensions) than to deploy QoS. The proposed requirements are too mechanism specific and not sufficiently high-level. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 17:50:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24387 for ; Fri, 28 Jun 2002 17:50:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05636; Fri, 28 Jun 2002 17:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05604 for ; Fri, 28 Jun 2002 17:46:28 -0400 (EDT) Received: from web20807.mail.yahoo.com (web20807.mail.yahoo.com [216.136.226.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24192 for ; Fri, 28 Jun 2002 17:45:41 -0400 (EDT) Message-ID: <20020628214626.48919.qmail@web20807.mail.yahoo.com> Received: from [134.193.6.40] by web20807.mail.yahoo.com via HTTP; Fri, 28 Jun 2002 14:46:26 PDT Date: Fri, 28 Jun 2002 14:46:26 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: RJ Atkinson , "Gunn, Janet NE" Cc: ieprep In-Reply-To: <2F97711F-8ADE-11D6-AA41-00039357A82A@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > So far, many ISPs have done the business analysis > and concluded that it > is more cost-effective to over-engineer their > networks (with redundancy, > capacity, and in other dimensions) than to deploy > QoS. I dont deny your statement.Redundany is the reason for robustness .But,the question before the house is : - if the load on days like 9/11 exceeds the backbone capacity * how quickly one can augument the capacity*.The time scale factor is very important as we are interested in short-time scales. - ISPs generally oversubscribe their links than overprovision.Will this be a factor ? - senthil __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 17:57:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24687 for ; Fri, 28 Jun 2002 17:57:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06403; Fri, 28 Jun 2002 17:56:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06369 for ; Fri, 28 Jun 2002 17:56:16 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24613 for ; Fri, 28 Jun 2002 17:55:28 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 17:55:07 -0400 Message-ID: From: "Gunn, Janet NE" To: "'ieprep@ietf.org'" Date: Fri, 28 Jun 2002 17:54:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] draft-berg-ieprep-sip-isup-gap-analysis-00 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org For some reason, I didn't get an automatic (official) announcement of this, so you may not have either. 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 : ISUP<>SIP Gap Analysis for IEPREP Author(s) : Dennis Berg Filename : draft-berg-ieprep-sip-isup-gap-analysis-00 Pages : 10 Date : 27-Jun-02 This document begins a gap analysis of SIP-ISUP mapping from the perspective of ieprep. Draft-ietf-sipping-isup-02 does not address mapping/translation for two ISUP IAM parameters of specific interest to ieprep: the mandatory Calling Party's Category and the optional Precedence parameters. On the assumption that both of these parameters should be mapped/translated in SIP-ISUP interworking, this ID begins with the proposal for a new SIP Resource-Priority header in work in progress in ieprep. Several variations on the proposed new header are formulated and assessed for use in mapping/translating the two IAM parameters. The ID concludes that either a single header with namespace differentiation of instances or two distinct headers would meet the needs of ieprep. It is recommended that this choice be made and reflected into draft-ietf-sipping-isup-02. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-berg-ieprep-sip-isup-gap-analysis- 00.txt Janet _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:00:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24782 for ; Fri, 28 Jun 2002 18:00:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06618; Fri, 28 Jun 2002 17:59:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06585 for ; Fri, 28 Jun 2002 17:59:37 -0400 (EDT) Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24744 for ; Fri, 28 Jun 2002 17:58:48 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 16:59:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Fri, 28 Jun 2002 16:59:32 -0500 Message-ID: Thread-Topic: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcIe5A/aO73RnZRMT96eOz0yv2NW4QACbjVQ From: "Beard, Cory" To: "RJ Atkinson" , "ieprep" X-OriginalArrivalTime: 28 Jun 2002 21:59:33.0208 (UTC) FILETIME=[15D4CD80:01C21EEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA06586 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Ran, I am surprised you read our draft differently, but the draft does indeed allow overprovisioning as a viable approach. Note specifically Sections 2.1 and 2.2, which say the fundamental requirements are availability and dependability, not necessarily preferential treatment. Section 2.1 on availability includes the following. "Service providers may choose to provide high availability levels through overprovisioning even when the network is stressed. They could choose to avoid using any mechanisms to identify or preferentially treat emergency traffic, because emergency traffic requirements would be met by the default operation of their network." Section 4.2 also says, "As an example, service providers may wish to provide service assurances for inelastic traffic using Diffserv [10] but use overprovisioning for both types of elastic traffic." That said, overprovisioning is treated with caution as a viable approach, especially because it would be hard to predict how the network would behave in all possible stress conditions. If you have suggestions on how to make the text more clear that overprovisioning is allowed, please advise. Cory Beard > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Friday, June 28, 2002 3:39 PM > To: ieprep > Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > > An underlying issue with this document is the assumption that > backbones might be under-provisioned. > > Many large backbones are in fact over-provisioned. That is, > they have more capacity than they have maximum potential offered load. > In many cases, this capacity is built on multiple wide-area SONET > rings, so that even an earthquake or smallish tactical nuclear bombs > would not cause them to be underprovisioned.[1] > > In such a network, QoS is not really a meaningful concept. It > seems to me that an operator with such a network might well be able > to provide the services desired for IEPREP without making any special > provisions in their network (other than ensuring robust overprovisioning > continues to be the case). > > That possibility is not reflected in this draft and seems like > a major omission to me. > > Ran > rja@extremenetworks.com > > [1] To be clear, most congestion and packet loss today occurs in the > access portion of the Internet, which is often operated by a smaller > Tier-2/3/4 provider different from the Tier-1 transit/backbone operator. > In this situation, QoS might be useful inside the Tier-N operator > (e.g. on particular access links that aren't overprovisioned by the > Tier-N > operator), but QoS would likely not be meaningful inside the Tier-1 > backbone. > > [2] Experience to date is that the Internet has not suffered from extreme > traffic loads (i.e. more than the Internet can handle) even in the > presence > of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th). > In fact, during such situations the "best effort" Internet has continued > to work quite well, thanks to a robust Internet Architecture. This fact > is also not reflected in the above draft -- and seems like a bug. > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:01:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24862 for ; Fri, 28 Jun 2002 18:01:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07239; Fri, 28 Jun 2002 18:01:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07203 for ; Fri, 28 Jun 2002 18:01:31 -0400 (EDT) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24828 for ; Fri, 28 Jun 2002 18:00:44 -0400 (EDT) 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.4905); Fri, 28 Jun 2002 17:01:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Fri, 28 Jun 2002 17:01:29 -0500 Message-ID: Thread-Topic: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcIe7VQLohPjTANUSa+Ju1QsMAo7jAAAdJtg From: "Beard, Cory" To: "senthil ayyasamy" , "RJ Atkinson" , "Gunn, Janet NE" Cc: "ieprep" X-OriginalArrivalTime: 28 Jun 2002 22:01:29.0617 (UTC) FILETIME=[5B376810:01C21EEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA07204 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] > - ISPs generally oversubscribe their links than > overprovision.Will this be a factor ? A distinction is that overprovisioning occurs in the core, and oversubscription in the access networks. Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:02:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24905 for ; Fri, 28 Jun 2002 18:02:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07319; Fri, 28 Jun 2002 18:02:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07287 for ; Fri, 28 Jun 2002 18:02:19 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24880; Fri, 28 Jun 2002 18:01:31 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-sb1-184-201.cisco.com [171.69.184.201]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SM1eOJ027921; Fri, 28 Jun 2002 15:01:40 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628150048.04dec668@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 15:01:39 -0700 To: Marshall Eubanks From: Fred Baker Subject: Re: [Ieprep] Re: MBONE in ieprep sessions Cc: Dinara Suleymanova , agenda@ietf.org, Scott Bradner , Allison Mankin , Steve Coya , Marcia Beaulieu , ieprep@ietf.org, tech@multicasttech.com In-Reply-To: <3D1CC1EB.5080005@multicasttech.com> References: <5.1.1.6.2.20020628095005.042dddb8@mira-sjcm-4.cisco.com> <5.1.1.6.2.20020628122800.025ada68@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:07 PM 6/28/2002 -0400, Marshall Eubanks wrote: >This is literally the first I have heard of this; but if >you have the bandwidth and a video feed, we can make the multicasts >happen. It would be convenient if this was in the DC area... that's not the question. IETF has multicast facilities on site, and broadcasts some sessions. They are already spoken for on Wednesday, but we can use them on Thursday. I hadn't asked before. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:12:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25422 for ; Fri, 28 Jun 2002 18:12:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08055; Fri, 28 Jun 2002 18:12:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08018 for ; Fri, 28 Jun 2002 18:12:18 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25398 for ; Fri, 28 Jun 2002 18:11:31 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-sb1-184-201.cisco.com [171.69.184.201]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SMBkOJ004112; Fri, 28 Jun 2002 15:11:46 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628151003.0506a100@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 15:11:44 -0700 To: RJ Atkinson From: Fred Baker Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Cc: ieprep In-Reply-To: <036A0EB7-8AD7-11D6-AA41-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:38 PM 6/28/2002 -0400, RJ Atkinson wrote: >Many large backbones are in fact over-provisioned. I point this out in the packet marking draft, and point out the places where one might expect to find an underprovisioned network (access and inter-campus links). Are you saying that the model needs to be repeated here? I'm quite willing to see an up-to-date traffic assessment in the draft. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25635 for ; Fri, 28 Jun 2002 18:16:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08486; Fri, 28 Jun 2002 18:16:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08398 for ; Fri, 28 Jun 2002 18:16:20 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25615 for ; Fri, 28 Jun 2002 18:15:33 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-sb1-184-201.cisco.com [171.69.184.201]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SMFmOJ006006; Fri, 28 Jun 2002 15:15:48 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628151305.050713a0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 15:15:47 -0700 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Cc: ieprep In-Reply-To: <20020628214626.48919.qmail@web20807.mail.yahoo.com> References: <2F97711F-8ADE-11D6-AA41-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 02:46 PM 6/28/2002 -0700, senthil ayyasamy wrote: >- if the load on days like 9/11 exceeds the backbone >capacity On 9/11, it's not clear that we significantly changed the utilization in the backbone. We re-routed some stuff due to fiber cuts and power supplies running out of fuel, but bluntly the Nimda and Code Red viruses had a more measurable effect on the net. >- ISPs generally oversubscribe their links than >overprovision.Will this be a factor ? last I heard, which is perhaps a year out of date, Qwest was running their links 2.5% utilized. I don't know of any service provider that runs their backbone links significantly more than 10% utilized. This is what Ran is getting at. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 18:37:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26316 for ; Fri, 28 Jun 2002 18:37:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09956; Fri, 28 Jun 2002 18:37:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09921 for ; Fri, 28 Jun 2002 18:37:13 -0400 (EDT) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26297 for ; Fri, 28 Jun 2002 18:36:23 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id PAA19400 for ; Fri, 28 Jun 2002 15:37:07 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id GYFTH100.F4B for ; Fri, 28 Jun 2002 15:36:37 -0700 Received: FROM agcs.com BY mkultra ; Fri Jun 28 15:36:40 2002 -0700 Message-ID: <3D1CE501.CD072C9@agcs.com> Date: Fri, 28 Jun 2002 15:36:49 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn Janet NE" CC: "'RJ Atkinson'" , ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: Content-Type: multipart/mixed; boundary="------------F7F41DB848254B3E081C15D9" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. --------------F7F41DB848254B3E081C15D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, It would seem that the ideal solution would apply to the network as a whole, without having to differentiate between backbone and edge. If we are concerned with a case where there is congestion in both the originating and terminating edges, it seems like the solution would apply regardless of the degree of congestion (or more likely absence of congestion) in the backbone. "Gunn, Janet NE" wrote: > While we have (luckily) not yet experienced it, it is quite possible to > imagine an emergency that causes a significant reduction in backbone > capacity. We should be prepared to address that. But I agree that > congestion/ lack of adequate provisioning at the "edges" is a more probable > case. > > Janet > > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Friday, June 28, 2002 4:39 PM > To: ieprep > Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > ... > > [2] Experience to date is that the Internet has not suffered from extreme > traffic loads (i.e. more than the Internet can handle) even in the > presence > of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th). > In fact, during such situations the "best effort" Internet has continued > to work quite well, thanks to a robust Internet Architecture. This fact > is also not reflected in the above draft -- and seems like a bug. > > _______________________________________________ > 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 --------------F7F41DB848254B3E081C15D9 Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org: adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;23888 fn:Stuart Goldman end:vcard --------------F7F41DB848254B3E081C15D9-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 19:17:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27815 for ; Fri, 28 Jun 2002 19:17:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12433; Fri, 28 Jun 2002 19:18:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12398 for ; Fri, 28 Jun 2002 19:18:22 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27789 for ; Fri, 28 Jun 2002 19:17:36 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 409AC67103; Fri, 28 Jun 2002 19:55:06 -0400 (EDT) Date: Fri, 28 Jun 2002 19:17:49 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ieprep" To: "Beard, Cory" From: RJ Atkinson In-Reply-To: Message-Id: <437A7CE4-8AED-11D6-807A-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 05:59 , Beard, Cory wrote: > That said, overprovisioning is treated with caution as a viable > approach, especially because it would be hard to predict how the network > would behave in all possible stress conditions. I don't follow the hard-to-predict claim. It is pretty easy to sum the max bandwidth of all the access links, then provision that much capacity throughout. I've worked on networks that engineered precisely on that basis to always have more capacity than max offered load. > If you have suggestions on how to make the text more clear that > overprovisioning is allowed, please advise. Please remove the reference and implication to specific mechanisms (example: QoS) from the requirements draft. Let the requirements draft focus on the high-level abstract requirements *only* (example: availability of capacity to handle IEPS traffic). Move all discussion of *mechanisms* to the other drafts. Right now, this draft inter-mingles discussion of mechanisms (e.g. QoS) with requirements (e.g. Availability) in an unfortunate manner. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 19:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27911 for ; Fri, 28 Jun 2002 19:19:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12566; Fri, 28 Jun 2002 19:20:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12520 for ; Fri, 28 Jun 2002 19:20:17 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27870 for ; Fri, 28 Jun 2002 19:19:31 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 5D26967103; Fri, 28 Jun 2002 19:57:01 -0400 (EDT) Date: Fri, 28 Jun 2002 19:19:40 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ieprep" To: "Beard, Cory" From: RJ Atkinson In-Reply-To: Message-Id: <85827FAE-8AED-11D6-807A-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 06:01 , Beard, Cory wrote: > A distinction is that overprovisioning occurs in the core, and > oversubscription in the access networks. Typically, yes. There exist examples of access networks that were also built in an over-provisioned manner (including several MANs in North America, Japan, Australia, and Europe). As you note, these are less common than under-provisioned access networks just now. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 19:26:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28217 for ; Fri, 28 Jun 2002 19:26:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13302; Fri, 28 Jun 2002 19:26:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13263 for ; Fri, 28 Jun 2002 19:26:41 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28200 for ; Fri, 28 Jun 2002 19:25:55 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id EBC5A67103; Fri, 28 Jun 2002 20:03:24 -0400 (EDT) Date: Fri, 28 Jun 2002 19:26:05 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: goldmans@agcs.com From: RJ Atkinson In-Reply-To: <3D1CE501.CD072C9@agcs.com> Message-Id: <6AFF1D95-8AEE-11D6-807A-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 06:36 , Stuart (Stu) Goldman wrote: > It would seem that the ideal solution would apply to the network as a > whole, > without having to differentiate between backbone and edge. Bad idea. Often the backbone is run by a service provider which wholesales transit service to a very separate access/edge network provider. These are distinct networks (e.g. separate AS, separate owners, contractual business relationships between them). Different mechanisms have different costs. It would be unfair to force all providers to use the same mechanism. > If we are concerned > with a case where there is congestion in both the originating and > terminating > edges, it seems like the solution would apply regardless of the degree > of > congestion (or more likely absence of congestion) in the backbone. If one edge were an over-provisioned MAN, then it ought not be required to implement the same mechanism as an edge that were an under-provisioned access network. We need to keep the Requirements draft very high-level with only abstract requirements (e.g. Availability) without discussing particular mechanisms or deployment strategies. There can then be some number of different drafts discussing various different kinds of mechanisms that an operator might consider. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 20:17:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29859 for ; Fri, 28 Jun 2002 20:17:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12121; Fri, 28 Jun 2002 19:14:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12093 for ; Fri, 28 Jun 2002 19:14:11 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27582 for ; Fri, 28 Jun 2002 19:13:24 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 21F2467103 for ; Fri, 28 Jun 2002 19:50:51 -0400 (EDT) Date: Fri, 28 Jun 2002 19:13:26 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <20020628214626.48919.qmail@web20807.mail.yahoo.com> Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 05:46 , senthil ayyasamy wrote: > But,the question before the house is : > > - if the load on days like 9/11 exceeds the backbone > capacity > * how quickly one can augument the capacity*.The time > scale factor is very important as we are interested in > short-time scales. It is, in fact, NOT the question in front of the WG. The question is whether to mandate a particular *mechanism* (namely QoS) in a document that purports to describe *high-level requirements*. Secondarily, my assertion is that many backbones are engineered to handle at least max(aggregate(access link bandwidth)) all the time. When an operator has their own facilities (e.g. fibre and DWDM equipment), it is often cheaper to over engineer a backbone than to deploy QoS or other mechanisms for dealing with contention. > - ISPs generally oversubscribe their links than > overprovision. That statement is false for most backbones in North America and for many backbones in other places around the world. It is true for many smaller Tier-2 or Tier-3 or Tier-4 access IP service providers. In particular, many of these smaller IP service providers lack their own facilities, which means they have a fundamentally different business model than large backbone operators having their own facilities. My comments were specifically using major backbones as the example. I perhaps should have qualified by saying "in North America", but that seems like a quibble rather than a material objection. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 20:48:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00588 for ; Fri, 28 Jun 2002 20:48:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17527; Fri, 28 Jun 2002 20:47:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17495 for ; Fri, 28 Jun 2002 20:47:58 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00565 for ; Fri, 28 Jun 2002 20:47:12 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5T0lQOJ002721; Fri, 28 Jun 2002 17:47:27 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628174316.0256f918@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 17:47:25 -0700 To: RJ Atkinson From: Fred Baker Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Cc: "ieprep" In-Reply-To: <85827FAE-8AED-11D6-807A-00039357A82A@extremenetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 07:19 PM 6/28/2002 -0400, RJ Atkinson wrote: >There exist examples of access networks that were also built in an >over-provisioned manner (including several MANs in North America, >Japan, Australia, and Europe). The point that has to be considered is not that there are examples of heavily overprovisioned networks in the core and in the access, or that there are examples otherwise, but that there are examples of both. Therefore, while I agree with you that overprovisioning works and is the choice made by a number of upper crust ISPs, it is not the only relevant solution. It seems to me that the requirements draft should be talking about the problem to be solved ("we need the phones and certain sites to be accessible be emergency workers when things are falling apart"), and if it mentioned solutions at all ("overprovisioning" or "QoS"), it should mention them as examples of a solution which can fix the problem being addressed, discussion of which can help identify requirements remaining to be addressed. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 20:55:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00707 for ; Fri, 28 Jun 2002 20:55:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17701; Fri, 28 Jun 2002 20:55:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17666 for ; Fri, 28 Jun 2002 20:55:46 -0400 (EDT) Received: from web20806.mail.yahoo.com (web20806.mail.yahoo.com [216.136.226.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00700 for ; Fri, 28 Jun 2002 20:55:00 -0400 (EDT) Message-ID: <20020629005544.65130.qmail@web20806.mail.yahoo.com> Received: from [134.193.6.40] by web20806.mail.yahoo.com via HTTP; Fri, 28 Jun 2002 17:55:44 PDT Date: Fri, 28 Jun 2002 17:55:44 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: RJ Atkinson , ieprep In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > The question is whether to mandate a particular > *mechanism* (namely QoS) > in a document that purports to describe *high-level > requirements*. > > Secondarily, my assertion is that many backbones are > engineered > to handle at least max(aggregate(access link > bandwidth)) all the > time. When an operator has their own facilities > (e.g. fibre > and DWDM equipment), it is often cheaper to over > engineer a > backbone than to deploy QoS or other mechanisms for > dealing > with contention. Ok..the options can be tabled like this: - Core * over-provision * QoS * traffic engineering - transit * co-operation between ISPs - access * QoS Some of the relevant issues: - At emergency times,if in some case,expected load exceeds the backbone capacity,how quickly you can increase the backbone capacity. If you cannot bring the network to normality within a short time scale,one have to go for QoS /traffic engineering options. Also,remember we are trying to give priority to emergency traffic and not create a robust network which will be a answer to all sort of congestion problems. - Access has the only option of using QoS to prioritize emergency traffic. - one should have a effective co-operation between service providers to accomodate emergency traffic.This can be addressed by means of peering or service level agreements only. - senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:02:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00920 for ; Fri, 28 Jun 2002 21:02:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18391; Fri, 28 Jun 2002 21:02:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18363 for ; Fri, 28 Jun 2002 21:02:23 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00896 for ; Fri, 28 Jun 2002 21:01:38 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g5T12NP24749 for ieprep@ietf.org; Fri, 28 Jun 2002 21:02:23 -0400 (EDT) Date: Fri, 28 Jun 2002 21:02:23 -0400 (EDT) From: Scott Bradner Message-Id: <200206290102.g5T12NP24749@newdev.harvard.edu> To: ieprep@ietf.org Subject: [Ieprep] (no subject) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Fred sed: > It seems to me that the requirements draft should be talking about the > problem to be solved ("we need the phones and certain sites to be > accessible be emergency workers when things are falling apart"), and if it > mentioned solutions at all ("overprovisioning" or "QoS"), it should mention > them as examples of a solution which can fix the problem being addressed, > discussion of which can help identify requirements remaining to be addressed. I think this is correct, but ieprep might also need to say what it means to have phones be "accessible [to] emergency workers" there is an a authentication part to this there is a privacy part to this there is a functionality part to this (e.g., what finctions are needed to say that a phone is "accessible") there is a quality part to this ( e.g., what are the characteristics of the required network-level functons, e.g., what qos variables, latency, bandwidth, loss, etc, apply, and how shoudl they be thought about there are other parts I'm sure Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:07:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01060 for ; Fri, 28 Jun 2002 21:07:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18468; Fri, 28 Jun 2002 21:07:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18434 for ; Fri, 28 Jun 2002 21:07:41 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01028 for ; Fri, 28 Jun 2002 21:06:56 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5T174OJ009256; Fri, 28 Jun 2002 18:07:04 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628180635.025d6a08@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 28 Jun 2002 18:07:03 -0700 To: RJ Atkinson From: Fred Baker Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Cc: "ieprep" In-Reply-To: References: <5.1.1.6.2.20020628174316.0256f918@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 09:01 PM 6/28/2002 -0400, RJ Atkinson wrote: >Since the I-D submissions have closed down, such a revision might >reasonably be put up on a web or ftp server with URL posted to the WG list >(as Fred did recently with one of his I-Ds). I would be willing to post it at the same site I did mine. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:08:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01080 for ; Fri, 28 Jun 2002 21:08:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18355; Fri, 28 Jun 2002 21:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18319 for ; Fri, 28 Jun 2002 21:01:58 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00888 for ; Fri, 28 Jun 2002 21:01:13 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id D471E67103; Fri, 28 Jun 2002 21:38:43 -0400 (EDT) Date: Fri, 28 Jun 2002 21:01:26 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ieprep" To: Fred Baker From: RJ Atkinson In-Reply-To: <5.1.1.6.2.20020628174316.0256f918@mira-sjcm-4.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 08:47 , Fred Baker wrote: > It seems to me that the requirements draft should be talking about the > problem to be solved ("we need the phones and certain sites to be > accessible be emergency workers when things are falling apart"), and if > it mentioned solutions at all ("overprovisioning" or "QoS"), it should > mention them as examples of a solution which can fix the problem being > addressed, discussion of which can help identify requirements remaining > to be addressed. I don't think it is clever to spend energy in the Requirements draft talking about any examples of implementation approaches. In any event, I think the current Requirements draft goes beyond mentioning example implementations and confuses requirements with implementation approaches. While I'm suggesting editorial changes to the Requirements draft, I think that a new section ("Scope") need to be added at the front of this draft. Proposed text for this follows: Scope: This document describes high-level requirements, but not implementation approaches, for networks that claim to provide Internet Emergency Preparedness Services (IEPS). Nothing in this document is applicable to an IP network that does NOT claim to provide such services. Discussion of how existing IETF standards-track technologies might be used to implement such capabilities is provided in several related, but separate, documents. I'd like to see an editorial pass on the Requirements document happen. I think it would be helpful if such a pass could happen prior to Yokohama. Since the I-D submissions have closed down, such a revision might reasonably be put up on a web or ftp server with URL posted to the WG list (as Fred did recently with one of his I-Ds). Yours, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:09:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01139 for ; Fri, 28 Jun 2002 21:09:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18548; Fri, 28 Jun 2002 21:09:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18514 for ; Fri, 28 Jun 2002 21:09:31 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01098 for ; Fri, 28 Jun 2002 21:08:45 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 66D4E67103; Fri, 28 Jun 2002 21:46:13 -0400 (EDT) Date: Fri, 28 Jun 2002 21:08:55 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: senthil ayyasamy From: RJ Atkinson In-Reply-To: <20020629005544.65130.qmail@web20806.mail.yahoo.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 08:55 , senthil ayyasamy wrote: > Ok..the options can be tabled like this: > - Core > * over-provision > * QoS > * traffic engineering > - transit > * co-operation between ISPs * overprovision * QoS * traffic engineering > - access > * QoS * overprovision * traffic engineering And even with those edits it is an incomplete table of options. Bottom line: - overprovisioning is a technique that can be used anyplace in the network - the requirements document needs to focus on high-level requirements and not confuse them with implementation options > Some of the relevant issues: > - At emergency times,if in some case,expected load > exceeds the backbone capacity,how quickly you can > increase the backbone capacity. > If you cannot bring the network to normality within > a short time scale,one have to go for QoS /traffic > engineering options. None of that is true if the backbone is over-engineered. > Also,remember we are trying to give priority to > emergency traffic and not create a robust network > which will be a answer to all sort of congestion > problems. Free clue: Many backbone operators *pride* themselves on not having *any* congestion inside their networks. So creating a robust network free from congestion *is* often their design and deployment goal. > - Access has the only option of using QoS to > prioritize emergency traffic. Not true. I've built MAN access networks that were over-provisioned. QoS is not required for those networks. And even if under-provisioned, QoS is NOT the only engineering option for the operator. > - one should have a effective co-operation between > service providers to accomodate emergency traffic.This > can be addressed by means of peering or service level > agreements only. That is essentially a business or contractual matter, hence explicitly outside the scope of the IETF. For anti-trust reasons, the IETF needs to stay away from making any recommendations about such business matters. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01485 for ; Fri, 28 Jun 2002 21:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18850; Fri, 28 Jun 2002 21:26:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18820 for ; Fri, 28 Jun 2002 21:26:30 -0400 (EDT) Received: from web20807.mail.yahoo.com (web20807.mail.yahoo.com [216.136.226.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01473 for ; Fri, 28 Jun 2002 21:25:44 -0400 (EDT) Message-ID: <20020629012629.74459.qmail@web20807.mail.yahoo.com> Received: from [134.193.6.40] by web20807.mail.yahoo.com via HTTP; Fri, 28 Jun 2002 18:26:29 PDT Date: Fri, 28 Jun 2002 18:26:29 -0700 (PDT) From: senthil ayyasamy Subject: doubts (was orginally ..Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt) To: RJ Atkinson Cc: ieprep In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I very much agree with your points.I have changed the subject to not disturbe the requiremenst drafts discussion. --- RJ Atkinson wrote: > > - transit > > * co-operation between ISPs > * overprovision Dont you think overprovisioing at the transit is little tricky . > > - Access has the only option of using QoS to > > prioritize emergency traffic. > > Not true. I've built MAN access networks that were > over-provisioned. QoS is not required for those > networks. And even if under-provisioned, QoS > is NOT the only engineering option for the operator. But,still at access they do less statistical multiplexing when compared to core.Multi-homing is also an option. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:37:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01732 for ; Fri, 28 Jun 2002 21:37:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19465; Fri, 28 Jun 2002 21:31:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19431 for ; Fri, 28 Jun 2002 21:31:43 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01555 for ; Fri, 28 Jun 2002 21:30:57 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 5336F67103; Fri, 28 Jun 2002 22:08:28 -0400 (EDT) Date: Fri, 28 Jun 2002 21:31:11 -0400 Subject: Re: [Ieprep] (no subject) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep@ietf.org To: Scott Bradner From: RJ Atkinson In-Reply-To: <200206290102.g5T12NP24749@newdev.harvard.edu> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 09:02 , Scott Bradner wrote: > Fred sed: >> It seems to me that the requirements draft should be talking about the >> problem to be solved ("we need the phones and certain sites to be >> accessible be emergency workers when things are falling apart"), and >> if it >> mentioned solutions at all ("overprovisioning" or "QoS"), it should >> mention >> them as examples of a solution which can fix the problem being >> addressed, >> discussion of which can help identify requirements remaining to be >> addressed. > > I think this is correct, but ieprep might also need to say what it > means to have phones be "accessible [to] emergency workers" > > there is an a authentication part to this > there is a privacy part to this > there is a functionality part to this (e.g., what finctions are needed > to say that a phone is "accessible") > there is a quality part to this ( e.g., what are the > characteristics of the required network-level functons, > e.g., what qos variables, latency, bandwidth, loss, etc, > apply, and how shoudl they be thought about > > there are other parts I'm sure Scott, I don't think you've got exactly the right list. If I could tweak it a bit, I would make your list read more like this: - security requirements: - user authentication - network integrity - user data confidentiality - network availability - routing integrity & availability (a path exists) - capacity (enough bandwidth exists for IEPS needs; subsumes packet loss) - network properties - jitter (maybe; I don't see that its needed, but maybe) - other - ... Things in your list above that aren't high-level requirements, but instead are really implementation/deployment strategies/details include: - QoS variables (no need for QoS if have overprovisioned capacity) - latency (varies by distance anyway and codecs/apps can adapt to large latency; see addition above of jitter which is more nearly relevant) Now it is helpful to have an array of informational documents describing possible deployment strategies (using existing IETF standards). An existing example is suggestions on configuring QoS with DiffServ, for operators who choose to participate in IEPS and also under-provision some part of the network and want to use DiffServ as part of their implementation approach. However, that other information ought be packaged *outside* the requirements document and kept purely optional to deploy. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:47:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02198 for ; Fri, 28 Jun 2002 21:47:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19754; Fri, 28 Jun 2002 21:47:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19720 for ; Fri, 28 Jun 2002 21:47:04 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02097 for ; Fri, 28 Jun 2002 21:46:19 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 723BB67103; Fri, 28 Jun 2002 22:23:50 -0400 (EDT) Date: Fri, 28 Jun 2002 21:46:33 -0400 Subject: Re: doubts (was orginally ..Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: senthil ayyasamy From: RJ Atkinson In-Reply-To: <20020629012629.74459.qmail@web20807.mail.yahoo.com> Message-Id: <0A36B389-8B02-11D6-807A-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, June 28, 2002, at 09:26 , senthil ayyasamy wrote: > Dont you think overprovisioing at the transit is little tricky . It is not intrinsically any harder than over-provisioning one's core. Any transit link of any sort involves close cooperation among the operators involved. Large backbones are likely to have their transit handled via dedicated links. NAPs are fading as a place that big operators exchange traffic. Most NAPs build on a non-blocking switch fabric (historically FDDI and ATM, more recently huge Ethernet switches). > But,still at access they do less statistical multiplexing when compared > to core. I don't follow your meaning at all. In particular, the phrase "statistical multiplexing" is quite confusing to me in the context of an IP network. The statistical multiplexing I think of is a method used in POTS telephony networks for reducing bandwidth consumed by voice telephone calls, by leveraging the tendency of humans to have silence in between words. The most popular deployment strategy today (at least in North America) is clearly SONET rings. Other popular technologies in backbone cores today include ATM. Such SONET or ATM is often built out on top of a DWDM system on dark fibre owned by (or under IRU to) the operator. I expect 10 Gig Ethernet to be part of the equation, more often in MAN than in WAN, by end of this calendar year. MAN networks tend to be built out of CWDM, SONET, ATM, and/or 1/10 Gig Ethernet. Access networks tend to be T1, T3, DSL, cable modems, and/or dialup modem banks (with very limited amounts of ISDN). [As noted in an earlier note, there is a bit of North American bias to the above summary.] > Multi-homing is also an option. Not sure what you mean by "multihoming is also an option". Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jun 28 21:53:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02437 for ; Fri, 28 Jun 2002 21:53:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19873; Fri, 28 Jun 2002 21:52:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19841 for ; Fri, 28 Jun 2002 21:52:47 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02411 for ; Fri, 28 Jun 2002 21:52:02 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g5T1qlw24911 for ieprep@ietf.org; Fri, 28 Jun 2002 21:52:47 -0400 (EDT) Date: Fri, 28 Jun 2002 21:52:47 -0400 (EDT) From: Scott Bradner Message-Id: <200206290152.g5T1qlw24911@newdev.harvard.edu> To: ieprep@ietf.org Subject: Re: [Ieprep] (no subject) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org from Ran's note I guess I was not clear what I tried to say was that we do not have an understanding of what an EPS phone call *is* in an Internet context I suppose that one could say that such a call must have a data path that acts basically like a dedicated private wire but that is not what the Internet is all about and it would be far from the most efficient way to provide for this service, and what does one say, if anything, about the signaling path? this list has been talking about prioritizing trafic (and making a requrement to tell SIP proxies, PSTN gateways, SIP nodes and who knows what else what priority to use and I do not know that strict priority is even the right concept (Fred has been talking about more complex concepts such as diffserv AF) so when we say "high level requirements" I am not sure we know what basic concepts the requirements need to fit into in the IP network in the gateway to the PSTN is seems clear that we need to have a way to tell that gateway what PSTN eps functions (for example MLPP) are being requested - but what do we want to tell (high level concept, not N-levels of priority, which is an implementaion concept) a SIP Proxy to do, or a router in the signaling path, or a router in the data path Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jun 29 00:38:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07344 for ; Sat, 29 Jun 2002 00:38:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26883; Sat, 29 Jun 2002 00:39:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26805 for ; Sat, 29 Jun 2002 00:39:00 -0400 (EDT) Received: from web20802.mail.yahoo.com (web20802.mail.yahoo.com [216.136.226.191]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07336 for ; Sat, 29 Jun 2002 00:38:12 -0400 (EDT) Message-ID: <20020629043858.7110.qmail@web20802.mail.yahoo.com> Received: from [134.193.24.26] by web20802.mail.yahoo.com via HTTP; Fri, 28 Jun 2002 21:38:58 PDT Date: Fri, 28 Jun 2002 21:38:58 -0700 (PDT) From: senthil ayyasamy Subject: Re: doubts (was orginally ..Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt) To: RJ Atkinson Cc: ieprep In-Reply-To: <0A36B389-8B02-11D6-807A-00039357A82A@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > > But,still at access they do less statistical > multiplexing when compared > > to core. > > I don't follow your meaning at all. In particular, > the phrase > "statistical > multiplexing" is quite confusing to me in the > context of an IP network. > The statistical multiplexing I think of is a method > used in POTS > telephony > networks for reducing bandwidth consumed by voice > telephone calls, by > leveraging the tendency of humans to have silence in > between words. I used the term for meaning *over booking*.Service providers overbook their access networks.This is the reason why a flash crowd can easily flood the access with core being unaffected.So,one can go for content distribution.It increases redundancy by load balacing but it doesnt allow one to give priority to emergency service.So,their should be a method for segregating the emergency packets from the SYN floods(which normally congests the newsites). >> Multi-homing is also an option. > >Not sure what you mean by "multihoming is also an >option". >--- RJ Atkinson wrote: >So creating a robust >network free from congestion *is* often their design >and deployment goal. Like how you increase the robustness in the core for supporting emergency traffic (as mentioned by you),you can get service from more than one service providers at the cost of increasing the AS connectivity complexity for robustness at the access.Will this be a factor too ???. - senthil ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jun 29 05:28:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21066 for ; Sat, 29 Jun 2002 05:28:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15671; Sat, 29 Jun 2002 05:28:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15639 for ; Sat, 29 Jun 2002 05:28:37 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21057 for ; Sat, 29 Jun 2002 05:27:51 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5T9SOxc028761; Sat, 29 Jun 2002 05:28:24 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-149-243.arcor-ip.net [212.144.149.243]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5T9SIpf004744 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 29 Jun 2002 05:28:22 -0400 (EDT) Message-ID: <3D1D7D87.3060605@cs.columbia.edu> Date: Sat, 29 Jun 2002 05:27:35 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker CC: senthil ayyasamy , ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: <2F97711F-8ADE-11D6-AA41-00039357A82A@extremenetworks.com> <5.1.1.6.2.20020628151305.050713a0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit I don't know if Abilene counts as a backbone provider in your book. According to http://loadrunner.uits.iu.edu/weathermaps/abilene/, a significant number of links are running well above 10 and some above 30%. And this is on a Saturday morning at 4 am, after the file-swapping undergraduates have left campuses for the semester... I would value contrary evidence. Fred Baker wrote: > At 02:46 PM 6/28/2002 -0700, senthil ayyasamy wrote: > >> - if the load on days like 9/11 exceeds the backbone >> capacity > > > On 9/11, it's not clear that we significantly changed the utilization in > the backbone. We re-routed some stuff due to fiber cuts and power > supplies running out of fuel, but bluntly the Nimda and Code Red viruses > had a more measurable effect on the net. > >> - ISPs generally oversubscribe their links than >> overprovision.Will this be a factor ? > > > last I heard, which is perhaps a year out of date, Qwest was running > their links 2.5% utilized. I don't know of any service provider that > runs their backbone links significantly more than 10% utilized. This is > what Ran is getting at. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jun 29 09:09:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24351 for ; Sat, 29 Jun 2002 09:09:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23934; Sat, 29 Jun 2002 09:09:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23902 for ; Sat, 29 Jun 2002 09:09:29 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24342 for ; Sat, 29 Jun 2002 09:08:38 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 78BB967103; Sat, 29 Jun 2002 09:46:11 -0400 (EDT) Date: Sat, 29 Jun 2002 09:08:50 -0400 Subject: Re: doubts (was orginally ..Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: senthil ayyasamy From: RJ Atkinson In-Reply-To: <20020629043858.7110.qmail@web20802.mail.yahoo.com> Message-Id: <5A7ACA0E-8B61-11D6-BE16-00039357A82A@extremenetworks.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Saturday, June 29, 2002, at 12:38 , senthil ayyasamy wrote: > Service providers overbook their access networks. Some providers underprovision ("overbook") their access networks. Some providers overprovision their access networks. Both situations exist in the deployed Internet. As noted before, I've personally deployed numerous MANs that were overprovisioned (because it was cheaper to do that than to deploy/operate QoS). > Like how you increase the robustness in the core for > supporting emergency traffic (as mentioned by you), > you can get service from more than one service providers > at the cost of increasing the AS connectivity > complexity for robustness at the access.Will this be a > factor too ???. I can't speak for folks who might want to purchase IEPREP services, not least because that is a large and very diverse set of folks, particularly since IETF needs to consider the issue globally, not just with a US focus. I doubt that every country will have the same deployment practices with regards to IEPREP. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jun 30 06:31:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27546 for ; Sun, 30 Jun 2002 06:31:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19266; Sun, 30 Jun 2002 06:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19234 for ; Sun, 30 Jun 2002 06:29:19 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27476 for ; Sun, 30 Jun 2002 06:28:31 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 30 Jun 2002 11:29:06 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Rohan Mahy cc: ieprep@ietf.org, hgs@cs.columbia.edu Subject: Re: [Ieprep] comments on draft-schulzrinne-ieprep-resource-req In-reply-to: Your message of "Fri, 28 Jun 2002 12:23:10 PDT." <7B97EE5E-8ACC-11D6-BA11-0003938AF740@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jun 2002 11:29:04 +0100 Message-ID: <13214.1025432944@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -Also, I think that the requirement implied in number 3 is cumbersome > and poorly stated. > what is the requirement here? is this a requirement that session setup > via SIP may need appropriate QoS marked or requested? if it is, say so > directly. as I read the draft, items 1 through 4 of the Introduction seemed more aimed at providing motivation for the R-P mechanism, as opposed to requirements. after points 1-4, actual requirements are stated. one thing that may help is to divide the Intro section into two parts: 1. Introduction, and 2. Requirements > - the security requirements are WAY underspecified. would it be possible to simply point to Ian Brown's draft and expand it if necessary to address the security concerns you may have? my personal view is that I would be a bit weary of placing a lot of security work in a requirements doc for a labeling mechanism. mind you, I'm not saying that security is a non-issue (actually, its quite critical). but I think because we have a number of drafts that need to address the subject, it would be easier to have consensus on a single document as opposed to trying to replicate in detail security requirements/issues in each and every document. my 2 cents, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jun 30 16:33:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10807 for ; Sun, 30 Jun 2002 16:33:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11371; Sun, 30 Jun 2002 16:33:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11339 for ; Sun, 30 Jun 2002 16:33:32 -0400 (EDT) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10783 for ; Sun, 30 Jun 2002 16:32:44 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id NAA01682 for ; Sun, 30 Jun 2002 13:33:30 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id GYJD3T00.5JY for ; Sun, 30 Jun 2002 13:33:29 -0700 Received: FROM agcs.com BY mkultra ; Sun Jun 30 13:33:26 2002 -0700 Message-ID: <3D1F6B26.35EE57E9@agcs.com> Date: Sun, 30 Jun 2002 13:33:42 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Carlberg CC: ieprep@ietf.org Subject: Re: [Ieprep] comments on draft-schulzrinne-ieprep-resource-req References: <13214.1025432944@cs.ucl.ac.uk> Content-Type: multipart/mixed; boundary="------------BD52BFF13C4F39D230B4AADE" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. --------------BD52BFF13C4F39D230B4AADE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken, You make an excellent point. If we were to attempt to replicate in detail security requirements/issues in each and every document, it is likely that the text would be slightly different as the security requirements evolved. By pointing to a single source one avoids the unintended differences. Ken Carlberg wrote: > > -Also, I think that the requirement implied in number 3 is cumbersome > > and poorly stated. > > what is the requirement here? is this a requirement that session setup > > via SIP may need appropriate QoS marked or requested? if it is, say so > > directly. > > as I read the draft, items 1 through 4 of the Introduction seemed more > aimed at providing motivation for the R-P mechanism, as opposed to > requirements. after points 1-4, actual requirements are stated. one > thing that may help is to divide the Intro section into two parts: > 1. Introduction, and 2. Requirements > > > - the security requirements are WAY underspecified. > > would it be possible to simply point to Ian Brown's draft > and expand it if necessary to address > the security concerns you may have? my personal view is that I would be > a bit weary of placing a lot of security work in a requirements doc > for a labeling mechanism. mind you, I'm not saying that security is > a non-issue (actually, its quite critical). but I think because we have > a number of drafts that need to address the subject, it would be easier to > have consensus on a single document as opposed to trying to replicate in > detail security requirements/issues in each and every document. > > my 2 cents, > > -ken > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------BD52BFF13C4F39D230B4AADE Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org: adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;23888 fn:Stuart Goldman end:vcard --------------BD52BFF13C4F39D230B4AADE-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep