From ieprep-admin@ietf.org Wed May 1 03:41: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 DAA03427 for ; Wed, 1 May 2002 03:41: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 DAA17242; Wed, 1 May 2002 03:41: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 DAA17204 for ; Wed, 1 May 2002 03:41:14 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03377 for ; Wed, 1 May 2002 03:41:06 -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 g417bC714541; Wed, 1 May 2002 08:37:12 +0100 From: "Alistair Munro" To: "'Fred Baker'" , Subject: RE: [Ieprep] IEPREP Interim Meeting? Date: Wed, 1 May 2002 08:41:49 +0100 Message-ID: <000401c1f0e3$a7179eb0$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <5.1.0.14.2.20020426191751.01b0e590@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, I won't be able to row across in time for this. Will you be able to host a teleconference during 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 > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of Fred Baker > Sent: 27 April 2002 00:23 > To: 'ieprep@ietf.org' > Subject: Re: [Ieprep] IEPREP Interim Meeting? > > > At 05:34 PM 4/24/2002 -0400, Gunn, Janet NE wrote: > >The minutes from the IEPREP WG meting say that an interim > meeting will > >be > >held in May or June. Have there been any developments on > date or locations? > > DISA (Don Choi) has offered to host a meeting in Washington > DC on May 20, > from 9:00 to 2:00. I'm technically a little late announcing > that - I should > have done so by April 20, for various reasons including > travel issues. My > lame excuse is that I visited DISA on Wednesday, and I wanted > to actually > announce the meeting subsequent to said visit. My reason for > calling an > interim is partly that I think we probably have enough on the > table to have > a useful discussion, and can lay out a road map in that > meeting towards a > consensus call on final documents agreed to in Yokohama. > > I would like, specifically, to discuss: > > - A presentation from DISA (proposed by Don Choi) > clarifying DISA issues > and requirements > - Henning Schulzrin's SIP MLPP and e911 requirements > - James Polk's SIP response to that draft > - Cory Beard's document > - an update to Hal's requirements document > - any changes that Ken has made to his framework proposal, > and the future > of that proposal > - direction for the BCP(s), including a table of contents and > solicitation of text for it > > And I would like to further discuss things that have been of > interest in on > the mailing list. We probably also have other things to > discuss; folks who > want to have a particular discussion should send me a note > privately or > post to the list. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 04:22: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 EAA06922 for ; Wed, 1 May 2002 04:22: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 EAA18708; Wed, 1 May 2002 04:21: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 EAA18674 for ; Wed, 1 May 2002 04:21:51 -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 EAA06918 for ; Wed, 1 May 2002 04:21:49 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 May 2002 09:21:46 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Alistair Munro cc: ieprep Subject: Re: [Ieprep] IEPREP Interim Meeting? In-reply-to: Your message of "Wed, 01 May 2002 08:41:49 BST." <000401c1f0e3$a7179eb0$31281eac@degree2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 May 2002 09:21:44 +0100 Message-ID: <540.1020241304@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 > I won't be able to row across in time for this. Will you be able to host > a teleconference during the meeting? a good question, and probably one that Fred will punt over to the host, DISA & Don Choi. Don, Will DISA be able to provide an Mbone feed of the meeting? And what arrangements, if any, need to be addressed for foreign nationals that wish to attend? will some type of a priori registration need to be done to enter your facility? -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailman-owner@ietf.org Wed May 1 07:04: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 HAA18767 for ; Wed, 1 May 2002 07:04: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 HAA17912 for ; Wed, 1 May 2002 07:04:57 -0400 (EDT) Date: Wed, 1 May 2002 07:04:57 -0400 (EDT) Message-Id: <200205011104.HAA17912@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 Wed May 1 09:14: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 JAA25974 for ; Wed, 1 May 2002 09:14: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 JAA12670; Wed, 1 May 2002 09:14: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 JAA12623 for ; Wed, 1 May 2002 09:13:52 -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 JAA25950 for ; Wed, 1 May 2002 09:13:49 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 09:13:52 -0400 Message-ID: From: "Choi, Don" To: "'Ken Carlberg'" Cc: ieprep , Alistair Munro Subject: RE: [Ieprep] IEPREP Interim Meeting? Date: Wed, 1 May 2002 09:13:50 -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, The location is likely to be The Sheration Reston Hotel, which is located a few miles east of Dulles airport on the Dulles Access Road. It is not far from CNRI. We will not be able to provide an Mbone feed. Don -----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Wednesday, May 01, 2002 4:22 AM To: Alistair Munro Cc: ieprep Subject: Re: [Ieprep] IEPREP Interim Meeting? > I won't be able to row across in time for this. Will you be able to host > a teleconference during the meeting? a good question, and probably one that Fred will punt over to the host, DISA & Don Choi. Don, Will DISA be able to provide an Mbone feed of the meeting? And what arrangements, if any, need to be addressed for foreign nationals that wish to attend? will some type of a priori registration need to be done to enter your facility? -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 May 1 09:18: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 JAA26145 for ; Wed, 1 May 2002 09:18: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 JAA12896; Wed, 1 May 2002 09: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 JAA12865 for ; Wed, 1 May 2002 09:18:18 -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 JAA26126 for ; Wed, 1 May 2002 09:18:14 -0400 (EDT) Received: from [24.28.197.67] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1349025; Wed, 01 May 2002 09:18:02 -0400 From: "Marshall Eubanks" Subject: Re: [Ieprep] IEPREP Interim Meeting? To: "Choi, Don" , "'Ken Carlberg'" Cc: ieprep , Alistair Munro X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Wed, 01 May 2002 09:18:02 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit On Wed, 1 May 2002 09:13:50 -0400 "Choi, Don" wrote: > Ken, > > The location is likely to be The Sheration Reston Hotel, > which is located a > few miles east of Dulles airport on the Dulles Access > Road. It is not far > from CNRI. > > We will not be able to provide an Mbone feed. > You could tunnel it to us over in Fairfax, and we could send it out in multicast. We could even bring in MPEG-1 or MPEG-4 encoding boxes to do this. Regards Marshall Eubanks 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 > Don > > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Wednesday, May 01, 2002 4:22 AM > To: Alistair Munro > Cc: ieprep > Subject: Re: [Ieprep] IEPREP Interim Meeting? > > > > > I won't be able to row across in time for this. Will > you be able to host > > a teleconference during the meeting? > > a good question, and probably one that Fred will punt > over to the host, > DISA & Don Choi. > > Don, > > Will DISA be able to provide an Mbone feed of the > meeting? > > And what arrangements, if any, need to be addressed for > foreign nationals > that wish to attend? will some type of a priori > registration need to > be done to enter your facility? > > -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 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 09:20:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26215 for ; Wed, 1 May 2002 09:19: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 JAA13054; Wed, 1 May 2002 09:19: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 JAA13009 for ; Wed, 1 May 2002 09:19:39 -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 JAA26208 for ; Wed, 1 May 2002 09:19:35 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 09:19:38 -0400 Message-ID: From: "Folts, Harold" To: "'ieprep@ietf.org'" Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Wed, 1 May 2002 09:19:32 -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 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 26, 2002 8:16 PM > To: ieprep@ietf.org > Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. > > > At 10:55 AM 4/11/2002 +0100, Alistair Munro wrote: > >functional/service requirements from the ETS side (your draft), and > >solutions from the IP side (Fred's draft). I like very much > your A. - K > >paragraphs in section 4 as a list of requirements for the ETS > > I agree that functional requirements are needed. If I can say > this without > appearing to slam Hal's draft (which I consider a very > reasonable start on > something which might be entitled "US Government requirements > of an ETS"), Its not appropriate to say US Government. The white paper was crafted with considerable industry interaction and input and I expect this to be done in partnership with industry. > I personally find it to be a list of glittering generalities, > some of which > are mutually contradictory. I'm not at all sure how to design > a service > that meets those requirements. I think there is more detail in the 11 "objectives/requirements" than first appear. Some of these do not necessarily fall with in the IETF scope. I am now preparing a revised version that I hope will zero in better without suggesting solutions. > > Let's take "the network must be secure" as an example (and of course > ignoring Ian's recent comments on the list). It is not clear > to me whether > the draft requires The issues you list below are far beyond what is needed for ETS. We need to keep it simple, yet effective. Two of the 11 address security - authorized user authentication and specific security protection of ETS traffic. The larger, global security issues with the Internet are being dealt with by folks competent in that area. Where is what is looked for these two items: 1. A more streamlined authentication scheme than the "credit card" method used for GETS today. Also the authentication must be passed along the path in an Internet environment, where it does not in the PSTN. 2. There is a need for specific security protection of ETS traffic. These include spoofing, impeding, and intrusion. These issues may be taken care of by the overall security provisions existing or being developed. Then all we need is to clearly describe how ETS traffic is protected. In addition, there will be some specific traffic that contains sensitive/classified information that will need to be encrypted or be non-traceable (if possible). The ETS must be provided using the shared public telecommunications resources, not dedicated, isolated networks. > > - Physical isolation of the network from the Internet > backbone (which > is seen as insecure), or > - Use of Code Division Multiple Access signaling to reduce the > probability of jamming interference with a radio signal, or > - Use of Ultra-Wideband signaling to provide limited probability of > detection of a radio signal, or > - Use of technologies to prevent and detect interference or > interdiction of a signal (such as placing fiber in a > pressurized ABS > pipe to detect attempts to bend the fiber to capture leaking > lambdas), or > - Use of type 1 encryption on all communications links, or > fragentation and reordering of traffic in a transaction with fill > traffic taking up any excess bandwidth on the line to prevent > or limit traffic analysis > - Strong authentication and perhaps encryption of every transaction > (email, web, file transfer, database access, whatever) end to end > using a mechanism such as IPSEC (is the blackberry to > blackberry or > IMM server to IMM server, or both?), or > - Continuity and privacy of communication needs to be > provided at the > transport layer in a manner which traverses firewalls and > NATs, such > as TLS, or > - Communication is required to be proof positive against denial of > service attacks, viruses, or worms, or > - Fast detection and operator interdiction of network overloads > resulting from such attacks, or > - Intrusion Detection Services (such as provided by a variety of > products including my company's Net Ranger product) need to be > deployed to automatically detect and interdict attacks, > - Firewalls (such as CheckPoint or PIX) need to be deployed for > perimeter protection, or > - Tracing of hackers and ddos attacks to their sources, > whether zombie > system or the actual script kiddie, or > - requiring ISPs to have their users "log in" in some manner (which > seems to me superfluous; they have their own requirements in this > area, dictated by their business), or > - Routing needs to neighbor authentication to reduce risk of > misrouting on incorrect data, or > - Each route needs to be digitally signed to preclude transitive > routing faults that neighbor authentication would not prevent, or > - Digital signatures on XML records to ensure their authenticity > in the database they were read from (eg, demonstrate to me that > the record presented to me as a library of congress record is in > fact from that place and is in fact exactly the authoritative > record that someone wrote there 32 years ago) > - Digital signatures on DNS records to ensure authenticated name-to- > address translation (DNSSEC), or > - Logging of all transactions (does that apply to DNS lookups? > Transmission of log records?), or > > - Reasonable and customary protections (including any or all of the > above as appropriate in the environment du jour) need to > be provided > against malicious or misconfigured behavior. > > I can think of communication environments where each of those > bullets is a > reasonable interpretation, and where it is in fact the operative > interpretation or part of it. My last bullet is (I hope Hal > doesn't mind me > trying to put words into his mouth) probably what is actually > intended. Again, I have not presented any solutions so that many alternatives and approaches can be considered to find the best solution. Hopefully, many of these can be accommodated with existing capabilities. Then we only need to describe how they fulfill the requirement or objective. Some may prove to not be solvable. The remainder would then need to be addressed through additional provisions in existing specs or those under development. Ideally, Separate dedicated standards would only be a last resort when there is nothing that fulfills a requirement. I will have a revised requirements/objectives document ready for the May 20th meeting. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 10:05: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 KAA28449 for ; Wed, 1 May 2002 10:05: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 KAA16033; Wed, 1 May 2002 10:05: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 KAA15997 for ; Wed, 1 May 2002 10:05:38 -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 KAA28425 for ; Wed, 1 May 2002 10:05:36 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 10:05:35 -0400 Message-ID: From: "Folts, Harold" To: "Choi, Don" , "'Ken Carlberg'" Cc: ieprep , Alistair Munro Subject: RE: [Ieprep] IEPREP Interim Meeting? Date: Wed, 1 May 2002 10:05:32 -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 Don, Why can't a simple teleconference capability be put in? I think it might be possible for someone to volunteer a bridge to be set up, but if not I will try NASA. Hal > -----Original Message----- > From: Choi, Don [mailto:choid@ncr.disa.mil] > Sent: Wednesday, May 01, 2002 9:14 AM > To: 'Ken Carlberg' > Cc: ieprep; Alistair Munro > Subject: RE: [Ieprep] IEPREP Interim Meeting? > > > Ken, > > The location is likely to be The Sheration Reston Hotel, > which is located a > few miles east of Dulles airport on the Dulles Access Road. > It is not far > from CNRI. > > We will not be able to provide an Mbone feed. > > Don > > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Wednesday, May 01, 2002 4:22 AM > To: Alistair Munro > Cc: ieprep > Subject: Re: [Ieprep] IEPREP Interim Meeting? > > > > > I won't be able to row across in time for this. Will you be > able to host > > a teleconference during the meeting? > > a good question, and probably one that Fred will punt over to > the host, > DISA & Don Choi. > > Don, > > Will DISA be able to provide an Mbone feed of the meeting? > > And what arrangements, if any, need to be addressed for > foreign nationals > that wish to attend? will some type of a priori registration need to > be done to enter your facility? > > -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 > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 11:30: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 LAA03284 for ; Wed, 1 May 2002 11:30: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 LAA20872; Wed, 1 May 2002 11:30: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 LAA20517 for ; Wed, 1 May 2002 11:28:13 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03159 for ; Wed, 1 May 2002 11:28:11 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41FRJpZ004312; Wed, 1 May 2002 08:27:19 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501082633.01af1a68@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 08:27:20 -0700 To: "Choi, Don" From: Fred Baker Subject: RE: [Ieprep] IEPREP Interim Meeting? Cc: "'Ken Carlberg'" , ieprep , Alistair Munro 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 09:13 AM 5/1/2002 -0400, Choi, Don wrote: >We will not be able to provide an Mbone feed. Any chance of a telephone? Cisco can provide a dial-in number if you can provide a phone capable of calling an 800 number. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 12:28: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 MAA07105 for ; Wed, 1 May 2002 12:28: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 MAA24875; Wed, 1 May 2002 12:28: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 MAA24838 for ; Wed, 1 May 2002 12:28:19 -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 MAA07063 for ; Wed, 1 May 2002 12:28:16 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 12:28:18 -0400 Message-ID: From: "Choi, Don" To: "Folts, Harold" Cc: ieprep , Alistair Munro , "'Ken Carlberg'" Subject: RE: [Ieprep] IEPREP Interim Meeting? Date: Wed, 1 May 2002 12:28:14 -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 Hal, We will put in a speakerphone. Can you look into getting a conference bridge? Don -----Original Message----- From: Folts, Harold Sent: Wednesday, May 01, 2002 10:06 AM To: Choi, Don; 'Ken Carlberg' Cc: ieprep; Alistair Munro Subject: RE: [Ieprep] IEPREP Interim Meeting? Don, Why can't a simple teleconference capability be put in? I think it might be possible for someone to volunteer a bridge to be set up, but if not I will try NASA. Hal > -----Original Message----- > From: Choi, Don [mailto:choid@ncr.disa.mil] > Sent: Wednesday, May 01, 2002 9:14 AM > To: 'Ken Carlberg' > Cc: ieprep; Alistair Munro > Subject: RE: [Ieprep] IEPREP Interim Meeting? > > > Ken, > > The location is likely to be The Sheration Reston Hotel, > which is located a > few miles east of Dulles airport on the Dulles Access Road. > It is not far > from CNRI. > > We will not be able to provide an Mbone feed. > > Don > > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Wednesday, May 01, 2002 4:22 AM > To: Alistair Munro > Cc: ieprep > Subject: Re: [Ieprep] IEPREP Interim Meeting? > > > > > I won't be able to row across in time for this. Will you be > able to host > > a teleconference during the meeting? > > a good question, and probably one that Fred will punt over to > the host, > DISA & Don Choi. > > Don, > > Will DISA be able to provide an Mbone feed of the meeting? > > And what arrangements, if any, need to be addressed for > foreign nationals > that wish to attend? will some type of a priori registration need to > be done to enter your facility? > > -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 > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 12:55:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08309 for ; Wed, 1 May 2002 12:55:22 -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 MAA26795; Wed, 1 May 2002 12:55: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 LAA21365 for ; Wed, 1 May 2002 11:33:13 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03466 for ; Wed, 1 May 2002 11:33:10 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g41FXBf07358 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 1 May 2002 08:33:12 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g41FXAO10554; Wed, 1 May 2002 08:33:11 -0700 (PDT) Subject: Re: [Ieprep] IEPREP Interim Meeting? To: Fred Baker Cc: "'ieprep@ietf.org'" Date: Wed, 1 May 2002 10:32:58 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Fred, Is this the official announcement of the meeting? Or will you be sending out something more? I will have trouble getting travel expense approval if I only have this e-mail that kind of informally discusses it. And of course to get a cheap airfare, I need an official announcement ASAP. If you have already sent out an official announcement and I missed it, I apologize. But could you then forward me a copy? Thanks in advance, Jim Fred Baker @ietf.org on 04/26/2002 06:23:13 PM Sent by: ieprep-admin@ietf.org To: "'ieprep @ietf.org'" cc: Subject: Re: [Ieprep] IEPREP Interim Meeting? At 05:34 PM 4/24/2002 -0400, Gunn, Janet NE wrote: >The minutes from the IEPREP WG meting say that an interim meeting will be >held in May or June. Have there been any developments on date or locations? DISA (Don Choi) has offered to host a meeting in Washington DC on May 20, from 9:00 to 2:00. I'm technically a little late announcing that - I should have done so by April 20, for various reasons including travel issues. My lame excuse is that I visited DISA on Wednesday, and I wanted to actually announce the meeting subsequent to said visit. My reason for calling an interim is partly that I think we probably have enough on the table to have a useful discussion, and can lay out a road map in that meeting towards a consensus call on final documents agreed to in Yokohama. I would like, specifically, to discuss: - A presentation from DISA (proposed by Don Choi) clarifying DISA issues and requirements - Henning Schulzrin's SIP MLPP and e911 requirements - James Polk's SIP response to that draft - Cory Beard's document - an update to Hal's requirements document - any changes that Ken has made to his framework proposal, and the future of that proposal - direction for the BCP(s), including a table of contents and solicitation of text for it And I would like to further discuss things that have been of interest in on the mailing list. We probably also have other things to discuss; folks who want to have a particular discussion should send me a note privately or post to the list. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:12: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 NAA09160 for ; Wed, 1 May 2002 13:12: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 NAA28110; Wed, 1 May 2002 13:12: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 NAA28032 for ; Wed, 1 May 2002 13:12:14 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09152 for ; Wed, 1 May 2002 13:12:11 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41HBdpZ025554; Wed, 1 May 2002 10:11:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501100949.02e88e90@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 10:11:40 -0700 To: James_Renkel@3com.com From: Fred Baker Subject: Re: [Ieprep] IEPREP Interim Meeting? 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:32 AM 5/1/2002 -0500, James_Renkel@3com.com wrote: >Is this the official announcement of the meeting? Or will you be sending >out something more? I will have trouble getting travel expense approval >if I only have this e-mail that kind of informally discusses it. And of >course to get a cheap airfare, I need an official announcement ASAP. I have sent an announcement to iesg-secretary@ietf.org to post, but Scott asked me to not include the agenda just yeat, so this note actually has more information than the announcement that you will see. Please tell your management that it is functionally equivalent to the announcement, which you should see later today on ietf-announce. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:28: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 NAA09947 for ; Wed, 1 May 2002 13:28: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 NAA28818; Wed, 1 May 2002 13:28: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 NAA28780 for ; Wed, 1 May 2002 13:28:29 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09908 for ; Wed, 1 May 2002 13:28:25 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41HRspZ003964; Wed, 1 May 2002 10:27:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501083832.0286c2a0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 10:27:54 -0700 To: "Folts, Harold" From: Fred Baker Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. 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 09:19 AM 5/1/2002 -0400, Folts, Harold wrote: >Its not appropriate to say US Government. The white paper was crafted with >considerable industry interaction and input and I expect this to be done in >partnership with industry. Your draft says A US Government working group recently identified fourteen basic functional requirements for the future ETS. These requirements are listed in the table below and represent the objectives that need to be fulfilled for national security and emergency preparedness (NS/EP) in the ETS. Specifically, some of the requirements (anonymity comes quickly to mind) have been explained to me as coming specifically from certain agencies in the US Government. If you'd like to reconsider some of that, I'm game, but at present the draft is very clearly a set of US Government requirements. >1. A more streamlined authentication scheme than the "credit card" method >used for GETS today. Also the authentication must be passed along the path >in an Internet environment, where it does not in the PSTN. > >2. There is a need for specific security protection of ETS traffic. These >include spoofing, impeding, and intrusion. May I suggest that you then break what you are calling "Security" into several requirements, and entitle them something like: "source (and destination?) authentication" ie, each participant needs to know whom he is talking to with a high level of confidence. We don't want "send in the national guard" to go to your favorite skinhead group... "source (and destination?) authorization to use the service" ie, a given service class needs to be used if and only if one of the parties to the conversation is authorized to use it. This, of course, depends on authentication, as already stated. The specifics of the "credit card" seem to me to be contract-specific. In my case, I have a program on my computer that generates a one-time password that I can use when dialing into Cisco. Several one-time-password-card products exist and could be used by other organizations that wanted that sort of service. I don't think the international standard wants to specify the use of a particular authentication mechanism or product, however; it wants to say that a contracted ETS wants to use an authentication mechanism that has the necessary characteristics to positively identify its user with high probability of correctness. It wants to leave the door open for retinal scans or whatever seems appropriate to the agency contracting the service. "assurance of minimum QoS" ie, the traffic within the specified class needs a certain guarantee of service as specified in the ETS contract, regardless of other traffic. This will require some form of policing (some on the list don't like diffserv, I'll let them specify an alternative that meets your requirement during a ddos storm) "assurance of end to end inviolability" ie, if there is an intrusion, it will not disrupt normal delivery of the real traffic. That very likely involves technology that provides a high probability of detecting and dealing with intrusion, but the specification should be that any such intrusion will be ineffective, not that it will not happen or that it will not remain undetected. >The ETS must be provided using the shared public telecommunications >resources, not dedicated, isolated networks. No problem; the way you get GETS on the telephone networks is by writing contracts with the telphone networks you want to use. Write the corollary contracts with the ISPs you want to use. As I told you a couple of years ago, the IETF is not a one-stop-shopping place for contracts. We can specify what things a service provider should be prepared to negotiate with you so that you can point to a document and say "the US Government will pay you for a service compliant with RFC ". At the end of the day, whether the ISP agrees to offer you the service,and how they implement it, will come out of the negotiation. >I will have a revised requirements/objectives document ready for the May >20th meeting. Thanks. This time I have allocated five hours; there should be no problem with you taking time to present it in detail. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:29: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 NAA09999 for ; Wed, 1 May 2002 13:29: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 NAA28948; Wed, 1 May 2002 13:29: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 NAA28903 for ; Wed, 1 May 2002 13:29:23 -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 NAA09984 for ; Wed, 1 May 2002 13:29:19 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 13:29:21 -0400 Message-ID: From: "Folts, Harold" To: "Choi, Don" Cc: ieprep , Alistair Munro , "'Ken Carlberg'" Subject: RE: [Ieprep] IEPREP Interim Meeting? Date: Wed, 1 May 2002 13:28:26 -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 > -----Original Message----- > From: Choi, Don > Sent: Wednesday, May 01, 2002 12:28 PM > To: Folts, Harold > Cc: ieprep; Alistair Munro; 'Ken Carlberg' > Subject: RE: [Ieprep] IEPREP Interim Meeting? > > > Hal, > > We will put in a speakerphone. Can you look into getting a > conference bridge? I'll give it a go, but I need to have a feel for how many will tune in. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:32: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 NAA10066 for ; Wed, 1 May 2002 13:32: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 NAA29551; Wed, 1 May 2002 13:31: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 NAA29512 for ; Wed, 1 May 2002 13:31:53 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10061 for ; Wed, 1 May 2002 13:31:49 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41HVJpZ005747 for ; Wed, 1 May 2002 10:31:19 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501102942.01ae8f80@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 10:31:19 -0700 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] teleconference 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 Question for the house: We're trying to work out how big a bridge is needed. How many folks would be likely to use a teleconference bridge if provided? How many would be likely to use an MBONE feed if provided? Answers to me privately if you would; let's not deep-six the list :^) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:54:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10760 for ; Wed, 1 May 2002 13:54: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 NAA00260; Wed, 1 May 2002 13:50: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 NAA00224 for ; Wed, 1 May 2002 13:50:45 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10679 for ; Wed, 1 May 2002 13:50:41 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g41Ho3x20689; Wed, 1 May 2002 12:50:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 12:49:57 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D802A531EC@zrc2c013.us.nortel.com> From: "Amarjit Deol" To: "'Fred Baker'" , ieprep@ietf.org Subject: RE: [Ieprep] teleconference Date: Wed, 1 May 2002 12:49:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F138.9AB880D0" 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_01C1F138.9AB880D0 Content-Type: text/plain; charset="iso-8859-1" Freed, We (Nortel) would use the conference bridge. BR, Amar Deol Nortel Networks email: deola@nortelnetworks.com The Contents of this Email are Nortel Networks Confidential -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Wednesday, May 01, 2002 12:31 PM To: ieprep@ietf.org Subject: [Ieprep] teleconference Question for the house: We're trying to work out how big a bridge is needed. How many folks would be likely to use a teleconference bridge if provided? How many would be likely to use an MBONE feed if provided? Answers to me privately if you would; let's not deep-six the list :^) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep ------_=_NextPart_001_01C1F138.9AB880D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ieprep] teleconference

Freed,
We (Nortel) would use the conference bridge.

BR,
Amar Deol
Nortel Networks
email: deola@nortelnetworks.com

The Contents of this Email are Nortel Networks = Confidential

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Wednesday, May 01, 2002 12:31 PM
To: ieprep@ietf.org
Subject: [Ieprep] teleconference


Question for the house:

We're trying to work out how big a bridge is needed. = How many folks would
be likely to use a teleconference bridge if = provided? How many would be
likely to use an MBONE feed if provided?

Answers to me privately if you would; let's not = deep-six the list :^)


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

------_=_NextPart_001_01C1F138.9AB880D0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 13:57: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 NAA10853 for ; Wed, 1 May 2002 13:57: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 NAA00551; Wed, 1 May 2002 13:57: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 NAA00516 for ; Wed, 1 May 2002 13:57:16 -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 NAA10841 for ; Wed, 1 May 2002 13:57:12 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 13:57:15 -0400 Message-ID: From: "Folts, Harold" To: "'Fred Baker'" Cc: "'ieprep@ietf.org'" Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Wed, 1 May 2002 13:57:10 -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 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, May 01, 2002 1:28 PM > To: Folts, Harold > Cc: 'ieprep@ietf.org' > Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. > > > At 09:19 AM 5/1/2002 -0400, Folts, Harold wrote: > >Its not appropriate to say US Government. The white paper > was crafted with > >considerable industry interaction and input and I expect > this to be done in > >partnership with industry. > > Your draft says > > A US Government working group recently identified fourteen basic > functional requirements for the future ETS. These > requirements are > listed in the table below and represent the objectives > that need to be > fulfilled for national security and emergency > preparedness (NS/EP) > in the ETS. That table was only intended to give a high-level introduction to the remainder of the paper. The table actually was developed with industry participation. It will be eliminated in the next draft because it really does not serve any purpose but confusion. The 11 requirements/objectives are what the focus should be. Not all of them will be relevant to the IETF so I will cull out the appropriate ones. > > Specifically, some of the requirements (anonymity comes > quickly to mind) > have been explained to me as coming specifically from certain > agencies in > the US Government. If you'd like to reconsider some of that, > I'm game, but > at present the draft is very clearly a set of US Government > requirements. The users of the ETS will range from local emergency people at the disaster scene all the way up the government ladder. At the local level there are the fire, police, medical, utility, and construction activities are involved. This is a mixture of government and private sector activities where the bulk of traffic would originate. At the higher government level the requirement for non-traceablity and encryption could come into play for particularly sensitive traffic. > > >1. A more streamlined authentication scheme than the "credit > card" method > >used for GETS today. Also the authentication must be passed > along the path > >in an Internet environment, where it does not in the PSTN. > > > >2. There is a need for specific security protection of ETS > traffic. These > >include spoofing, impeding, and intrusion. > > May I suggest that you then break what you are calling > "Security" into > several requirements, and entitle them something like: > > "source (and destination?) authentication" Destination not required. Communications originated by an authorized user can go to any destination. > > ie, each participant needs to know whom he is talking > to with a high > level of > confidence. We don't want "send in the national guard" > to go to your > favorite > skinhead group... > > "source (and destination?) authorization to use the service" > > ie, a given service class needs to be used if and only > if one of the > parties > to the conversation is authorized to use it. This, of > course, depends on > authentication, as already stated. > > The specifics of the "credit card" seem to me to be > contract-specific. In my case, > I have a program on my computer that generates a > one-time password > that I can use > when dialing into Cisco. Several one-time-password-card > products > exist and could > be used by other organizations that wanted that sort of > service. I > don't think the > international standard wants to specify the use of a particular > authentication > mechanism or product, however; it wants to say that a > contracted ETS > wants to use > an authentication mechanism that has the necessary > characteristics to > positively > identify its user with high probability of correctness. > It wants to > leave the door > open for retinal scans or whatever seems appropriate to > the agency > contracting the > service. > > "assurance of minimum QoS" > > ie, the traffic within the specified class needs a > certain guarantee > of service as > specified in the ETS contract, regardless of other > traffic. This will > require some > form of policing (some on the list don't like diffserv, > I'll let them > specify an > alternative that meets your requirement during a ddos storm) > > "assurance of end to end inviolability" > > ie, if there is an intrusion, it will not disrupt > normal delivery of > the real traffic. > That very likely involves technology that provides a > high probability > of detecting > and dealing with intrusion, but the specification > should be that any > such intrusion > will be ineffective, not that it will not happen or > that it will not > remain undetected. Let's keep it simple. There is a specific mission for the ETS - provide assured communications for emergency recovery activities to save lives and restore community infrastructure. > > > >The ETS must be provided using the shared public telecommunications > >resources, not dedicated, isolated networks. > > No problem; the way you get GETS on the telephone networks is > by writing > contracts with the telephone networks you want to use. Write > the corollary > contracts with the ISPs you want to use. We plan to apply SLAs to the provisioning of ETS. We are working with the TMForum in the development of edition 2 of the industry SLA Handbook to include provisions for the ETS. > > As I told you a couple of years ago, the IETF is not a > one-stop-shopping > place for contracts. We can specify what things a service > provider should > be prepared to negotiate with you so that you can point to a > document and > say "the US Government will pay you for a service > compliant with > RFC ". At the end of the day, whether the ISP > agrees to offer you > the service,and how they implement it, will come out of the > negotiation. All that we are looking for in the IETF are the technical provisions that will facilitate establishment of preferential treatment of emergency communications in the public telecommunications infrastructure to support disaster recover operations. Preferential treatment only comes into play when network resources are severely constrained and cannot handle the critical emergency traffic. Otherwise ETS traffic would be treated the same as all communications. > > >I will have a revised requirements/objectives document ready > for the May > >20th meeting. > > Thanks. This time I have allocated five hours; there should > be no problem > with you taking time to present it in detail. > Thanks Fred, I will be there. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 1 14:55:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18042 for ; Wed, 1 May 2002 14:55:30 -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 OAA03352; Wed, 1 May 2002 14:55: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 OAA03315 for ; Wed, 1 May 2002 14:55:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17969 for ; Wed, 1 May 2002 14:55:01 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41IsVpZ016198; Wed, 1 May 2002 11:54:31 -0700 (PDT) Message-Id: <5.1.0.14.2.20020501111608.02dd5400@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 11:54:31 -0700 To: "Amarjit Deol" From: Fred Baker Subject: RE: [Ieprep] teleconference Cc: ieprep@ietf.org In-Reply-To: <6B49EDFE974BD51197D70002A56079D802A531EC@zrc2c013.us.norte l.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:49 PM 5/1/2002 -0500, Amarjit Deol wrote: >We (Nortel) would use the conference bridge. how many callers would do so? We are trying to figure out how many ports are needed. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 2 04:15: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 EAA00207 for ; Thu, 2 May 2002 04:15: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 EAA18339; Thu, 2 May 2002 04:14: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 EAA18302 for ; Thu, 2 May 2002 04:14:38 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00165 for ; Thu, 2 May 2002 04:14:30 -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 g428EA732383; Thu, 2 May 2002 09:14:10 +0100 From: "Alistair Munro" To: "'Fred Baker'" , "'Folts, Harold'" Cc: Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Thu, 2 May 2002 09:18:48 +0100 Message-ID: <002601c1f1b1$fc8a44f0$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 In-Reply-To: <5.1.0.14.2.20020501083832.0286c2a0@mira-sjcm-4.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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, Hal, > > Your draft says > > A US Government working group recently identified fourteen basic > functional requirements for the future ETS. These > requirements are > listed in the table below and represent the objectives > that need to be > fulfilled for national security and emergency > preparedness (NS/EP) > in the ETS. > I'm trying to get a view from my APCO contacts in the UK on the differences in requirements but I don't have much hope of being able to be specific. Can we state a working assumption that these requirements may be different in other countries, update the requirements and then ask for comments from local agencies? 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 Thu May 2 08:22: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 IAA17767 for ; Thu, 2 May 2002 08:22: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 IAA02196; Thu, 2 May 2002 08:22: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 IAA02162 for ; Thu, 2 May 2002 08:22:07 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17731 for ; Thu, 2 May 2002 08:22:03 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 2 May 2002 13:21:50 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Alistair Munro cc: ieprep Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. In-reply-to: Your message of "Thu, 02 May 2002 09:18:48 BST." <002601c1f1b1$fc8a44f0$31281eac@degree2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 May 2002 13:21:49 +0100 Message-ID: <962.1020342109@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 > I'm trying to get a view from my APCO contacts in the UK on the > differences in requirements but I don't have much hope of being able to > be specific. Can we state a working assumption that these requirements > may be different in other countries, update the requirements and then > ask for comments from local agencies? my hope would be that the differences between other countries would be quite small, and mostly a reflection of local laws and regulation that amount to turn-on or turn off feature X. if you're going down the avenue of APCO, you may want to take a look at Project 25 (i believe they have high level comms Requirements), as well as the final report of the Public Safety Wireless Advisory Committee, circa 1996. (if you ask where to get them, i'm afraid i have to plead ignorance -- perhaps a google search will help) -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 2 08:50: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 IAA20179 for ; Thu, 2 May 2002 08:50: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 IAA03743; Thu, 2 May 2002 08:49: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 IAA03711 for ; Thu, 2 May 2002 08:49: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 IAA20088 for ; Thu, 2 May 2002 08:49:18 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id D1E7867103; Thu, 2 May 2002 09:17:43 -0400 (EDT) Date: Thu, 2 May 2002 08:48:42 -0400 Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep To: Ken Carlberg From: RJ Atkinson In-Reply-To: <962.1020342109@cs.ucl.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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 Thursday, May 2, 2002, at 08:21 , Ken Carlberg wrote: > my hope would be that the differences between other countries would be > quite small, and mostly a reflection of local laws and regulation that > amount to turn-on or turn off feature X. I have specific reason to believe that European requirements vary significantly from the US requirements. And the Japanese presentations at IETF have so far been fairly different from the DISA presentations. So I think it would be very unwise for an *international* activity like IETF to get driven primarily by US requirements. I second Alistair's request to note the existence of national variation in requirements and to put more efforts into getting inputs from other nations/areas/regions than the US. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 2 10:01:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27005 for ; Thu, 2 May 2002 10:01: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 KAA08887; Thu, 2 May 2002 10:00: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 KAA08846 for ; Thu, 2 May 2002 10:00:13 -0400 (EDT) Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26869 for ; Thu, 2 May 2002 10:00:08 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v32.5.) id l.1bd.8e52d4 (30970) for ; Thu, 2 May 2002 09:59:30 -0400 (EDT) Message-ID: <1bd.8e52d4.2a02a042@aol.com> Date: Thu, 2 May 2002 09:59:30 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1bd.8e52d4.2a02a042_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] May 20 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 --part1_1bd.8e52d4.2a02a042_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, The specifics for the IEPREP interim meeting location: May 20 9AM - 2PM Sheraton Reston 11810 Sunrise Valley Drive Reston, VA 20191 +1 703-620-9000 From Dulles airport, take Dulles Airport Access road east (toward Washinton) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building). From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above. Information concerning telephone conference setup will be provided. Questions on location, etc, please contact me. Please send me an e-mail (privately) if you plan to attend so that we can get a better idea of how much coffee to make :) Mike Pierce --part1_1bd.8e52d4.2a02a042_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

The specifics for the IEPREP interim meeting location:

May 20 9AM - 2PM
Sheraton Reston
11810 Sunrise Valley Drive
Reston, VA 20191
+1 703-620-9000

From Dulles airport, take Dulles Airport Access road east (toward Washinton) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building).

From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above.

Information concerning telephone conference setup will be provided.

Questions on location, etc, please contact me.

Please send me an e-mail (privately) if you plan to attend so that we can get a better idea of how much coffee to make :)

Mike Pierce
--part1_1bd.8e52d4.2a02a042_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 2 12: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 MAA09251 for ; Thu, 2 May 2002 12:01: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 LAA16755; Thu, 2 May 2002 11:55:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16727 for ; Thu, 2 May 2002 11:55:08 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08682 for ; Thu, 2 May 2002 11:55:04 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-41.cisco.com [128.107.163.41]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g42FsPpZ002987; Thu, 2 May 2002 08:54:25 -0700 (PDT) Message-Id: <5.1.0.14.2.20020502085323.026c2eb8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 May 2002 08:54:25 -0700 To: RJ Atkinson From: Fred Baker Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. Cc: Ken Carlberg , ieprep In-Reply-To: References: <962.1020342109@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 08:48 AM 5/2/2002 -0400, RJ Atkinson wrote: >So I think it would be very unwise for an *international* activity >like IETF to get driven primarily by US requirements. I agree, and that is exactly why I have pointed out that these are USG requirements. Not that this makes them invalid, but it makes them one view of the elephant. We need to make sure that we solve the problem for the elephant, not the wise guy standing beside it. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri May 3 10:28: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 KAA15131 for ; Fri, 3 May 2002 10:28: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 KAA09158; Fri, 3 May 2002 10:21: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 KAA09120 for ; Fri, 3 May 2002 10:21:06 -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 KAA14928 for ; Fri, 3 May 2002 10:21:01 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 10:21:04 -0400 Message-ID: From: "Folts, Harold" To: "'Alistair Munro'" , "'Fred Baker'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Fri, 3 May 2002 10:21:01 -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: Alistair Munro [mailto:alistair.munro@degree2.com] > Sent: Thursday, May 02, 2002 4:19 AM > To: 'Fred Baker'; 'Folts, Harold' > Cc: ieprep@ietf.org > Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. > > > Hi Fred, Hal, > > > > > Your draft says > > > > A US Government working group recently identified > fourteen basic > > functional requirements for the future ETS. These > > requirements are > > listed in the table below and represent the objectives > > that need to be > > fulfilled for national security and emergency > > preparedness (NS/EP) > > in the ETS. > > > > I'm trying to get a view from my APCO contacts in the UK on the > differences in requirements but I don't have much hope of > being able to > be specific. Can we state a working assumption that these requirements > may be different in other countries, update the requirements and then > ask for comments from local agencies? Alistair, We are attempting to establish a basic set of authorized emergency telecommunications that are standardized internationally. Individual countries can then establish their own policies on what/how to implement and how to configure for their specific requirements. The only point that is critical is that emergency communications cross national gateways to other countries. Emergency traffic between countries will most likely be subject to policies of bilateral agreement. The current edition of my white paper gives the overall big picture of requirements and objectives. The new version I am working on will focus more specifically on those requirements that need to be focused on in the IETF. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri May 3 11:28: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 LAA16892 for ; Fri, 3 May 2002 11:28: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 LAA12562; Fri, 3 May 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 LAA12527 for ; Fri, 3 May 2002 11:22:01 -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 LAA16782 for ; Fri, 3 May 2002 11:21:56 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 8D0EC67103; Fri, 3 May 2002 11:50:40 -0400 (EDT) Date: Fri, 3 May 2002 11:21:30 -0400 Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep To: "Folts, Harold" From: RJ Atkinson In-Reply-To: Message-Id: <717EEEE5-5EA9-11D6-B6CA-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 3, 2002, at 10:21 , Folts, Harold wrote: > The current edition of my white paper gives the overall big picture of > requirements and objectives. The new version I am working on will focus > more > specifically on those requirements that need to be focused on in the > IETF. Nit. Your white paper gives *an* overall big picture. Some of us have concerns that other countries and regions have different overall big pictures. The only way I see to resolve those concerns fully is to get folks from other regions and countries more actively involved here. Whether we can find those folks and get them to be involved here is unclear, but various folks are trying. Cheers, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 6 10:59: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 KAA22291 for ; Mon, 6 May 2002 10:59: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 KAA25607; Mon, 6 May 2002 10:58:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25575 for ; Mon, 6 May 2002 10:58:25 -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 KAA22234 for ; Mon, 6 May 2002 10:58:19 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 10:58:24 -0400 Message-ID: From: "Folts, Harold" To: "'RJ Atkinson'" Cc: ieprep Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Mon, 6 May 2002 10:58:23 -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 > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Thursday, May 02, 2002 8:49 AM > To: Ken Carlberg > Cc: ieprep > Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. > > > > On Thursday, May 2, 2002, at 08:21 , Ken Carlberg wrote: > > my hope would be that the differences between other > countries would be > > quite small, and mostly a reflection of local laws and > regulation that > > amount to turn-on or turn off feature X. > > I have specific reason to believe that European > requirements vary > significantly from the US requirements. And the Japanese > presentations > at IETF have so far been fairly different from the DISA presentations. > > So I think it would be very unwise for an > *international* activity > like IETF to get driven primarily by US requirements. I second > Alistair's > request to note the existence of national variation in requirements > and to put more efforts into getting inputs from other > nations/areas/regions > than the US. > Ran, let me provide you some very important background. Over the past 2.5 years, I have been very active in collaboration with many nations around the world. The requirements that I have been addressing are inclusive so that truly International solutions are established. These issues are being addressed in the following regional and international organizations: 1. Nine Study Groups of the ITU - the original ITU-T Recommendation E.106 was agreed upon in March 2000. E.106 is the International Emergency Preference Scheme was posted at an ID some time ago and is well referenced in my white paper. Draft ITU-T Recommendation F.706, Service Definition for the International Emergency Multimedia Service, is in final approval stage of approval, which is expected in October 2001. It also is well referenced in my white paper. 2. The NATO Civil Communications Planning Committee (CCPC) of the civil side, not military side, of NATO. They actually originated the draft that became ITU-T Rec E.106. 3. European Telecommunications Standards Institute (ETSI) has an active program underway for emergency telecommunications (EMTEL), with Projects MESA, TIPHON, and 3GPP. These projects are open to full international participation. ETSI had a very successful EMTEL workshop in February that had participation from many countries and emergency organizations within those countries. 4. IETF for over 2 years has been provided specific technical proposals ad IDs that have been open to discussion and input from the collective international participants in the working groups and via the lists ieps and ieprep. 5. United Nations Working Group on Emergency Telecommunications (WGET). I have also personally collaborated with Japan, United Kingdom, Canada, Germany as well as interacted with representatives from many countries in all of the above activities. Yes we must have participation from other nations and we have already kept their views and input in full consideration of progressing this work. Continuing participation is not only welcome but encouraged. While my white paper did include a table of 14 requirements that were identified by a US Government committee, they are mostly high level "ity" aspects and only serve as a very general basis for emergency telecommunications overall. The more specific 11 requirements/objectives have, in fact, considered requirements of other nations. For example, the optional preemption requirement that has been included. Preemption in US public telecommunication networks is not allowed. All of the others have been widely presented internationally, well discussed, and well received. I could go further and include other references that have been considered: 1. ITU-D Handbook on Disaster Communications, published 2001 2. Tampere Convention on the Provision of Telecommunication Resources for Disaster Mitigation and Relief Operations - June 1998 3. Second Tampere Conference on Disaster Communications - May 2001 4. World Telecommunication Development Conference - Resolutions 172 and 255, Istanbul, Turkey 18-27 March 2002. I am personally active in this work as systems engineer for emergency telecommunications under a task in the National Communications System, which is a confederation of 22 Federal agencies. Only one of these agencies is DoD. I am with NASA on detail to the NCS. DISA MLPP requirements represent only one component, of many others, of the overall work for emergency telecommunications to support recovery operations from serious disaster events. All requirements from participating nations will continue to be addressed in the work as it progressed toward internationally agreed upon solutions. The emergency telecommunications work for future networks is multidimensional and addresses many aspects. Not all these are of concern to the IETF and are being addressed in the other appropriate organizations. The revised requirements document that I am working on will be presenting the requirements/objectives from the white paper that should appropriately be addressed by the IETF. Others are being addressed by other responsible organizations. My last point is that this effort is not only government driven, but is being done in close cooperation and partnership with the telecommunications industry in many countries. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 6 11:11: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 LAA22987 for ; Mon, 6 May 2002 11:11: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 LAA27290; Mon, 6 May 2002 11:08: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 LAA27113 for ; Mon, 6 May 2002 11:08: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 LAA22794 for ; Mon, 6 May 2002 11:08:44 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id CF6E267103; Mon, 6 May 2002 11:37:54 -0400 (EDT) Date: Mon, 6 May 2002 11:08:15 -0400 Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep To: "Folts, Harold" From: RJ Atkinson In-Reply-To: Message-Id: <16FB3EBB-6103-11D6-AFB5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 6, 2002, at 10:58 , Folts, Harold wrote: > Ran, let me provide you some very important background. > > Over the past 2.5 years, I have been very active in collaboration with > many > nations around the world. The requirements that I have been addressing > are > inclusive so that truly International solutions are established. Harold, It is important in an IETF context for the other players you mention to actually show up and participate here. No matter how well intentioned any human might be, people make mistakes or forget things or overlook things. The IETF needs to have visible public agreement from folks outside the US that the approach being taken within IETF is internationally agreeable. No one person is *capable* of providing assurance of that needed public agreement. So trying to present yourself as the one person who has everyone's requirements is well-intentioned, but not nearly sufficient. If you are in contact with so many folks as you outline, you should undertake active measures to get those other folks to show up at IETF and participate directly for themselves here. That will demonstrate the kind of broad multi-national support that is needed. And nothing less will really be sufficient. Regards, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 6 15: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 PAA03067 for ; Mon, 6 May 2002 15: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 OAA12540; Mon, 6 May 2002 14:54: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 OAA12506 for ; Mon, 6 May 2002 14:54:36 -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 OAA02857 for ; Mon, 6 May 2002 14:54:25 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 14:54:32 -0400 Message-ID: From: "Folts, Harold" To: "ieprep List (E-mail)" Date: Mon, 6 May 2002 14:54:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] RE: ieprep telecom 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 made arrangements for a conference bridge through NASA. It is for 20 May from 9:00 am to 2:00 pm It is toll-free dial-in @ 888 820-8951 Pass Code 25508 Conf leader: Hal Folts You will need to provide the pass code and my name when asked. I have 10 ports including the one for the meeting. I can add more if there is an indication of more than 9 dialing in. Hal > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 02, 2002 2:24 AM > To: Folts, Harold > Subject: Re: ieprep telecom > > > At 01:01 PM 5/1/2002 -0400, Folts, Harold wrote: > >How many would you expect to tune into a teleconference > bridge for the > >meeting? > > so far I have seven who have said they would like to have the > facility. My > inclination is to overshoot a little and allow for ten. If I > get a larger > number than that, I'll let you know. > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 6 15:53: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 PAA04542 for ; Mon, 6 May 2002 15:53: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 PAA16008; Mon, 6 May 2002 15:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15978 for ; Mon, 6 May 2002 15:53:26 -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 PAA04525 for ; Mon, 6 May 2002 15:53:19 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 15:53:25 -0400 Message-ID: From: "Folts, Harold" To: "'RJ Atkinson'" Cc: ieprep Subject: RE: [Ieprep] What next?, getting to the BCP deliverable. Date: Mon, 6 May 2002 15:53:23 -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 > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Monday, May 06, 2002 11:08 AM > To: Folts, Harold > Cc: ieprep > Subject: Re: [Ieprep] What next?, getting to the BCP deliverable. > > > > On Monday, May 6, 2002, at 10:58 , Folts, Harold wrote: > > Ran, let me provide you some very important background. > > > > Over the past 2.5 years, I have been very active in > collaboration with > > many > > nations around the world. The requirements that I have been > addressing > > are > > inclusive so that truly International solutions are established. > > Harold, > > It is important in an IETF context for the other > players you mention > to actually show up and participate here. No matter how well > intentioned > any human might be, people make mistakes or forget things or overlook > things. > The IETF needs to have visible public agreement from folks outside the > US that the approach being taken within IETF is internationally > agreeable. > > > No one person is *capable* of providing assurance of > that needed public > agreement. So trying to present yourself as the one person who has > everyone's > requirements is well-intentioned, but not nearly sufficient. > > If you are in contact with so many folks as you > outline, you should > undertake active measures to get those other folks to show up at IETF > and participate directly for themselves here. That will > demonstrate the > kind of broad multi-national support that is needed. And nothing less > will really be sufficient. Ran, I am have given and will continue many briefings to interested groups that include identification of all the many activities that are underway. This includes the IETF work. I always encourage people to participate in this work. However, the requirements people are not very interested in getting into the nitty gritty of the IETF work. I agree that one person cannot convey all the first hand requirements, but on the other hand, I do provide status reports to most of these other activities on the progress of work, including the IETF. That's the best we can hope for at the moment. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri May 10 07:36:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15224 for ; Fri, 10 May 2002 07:36:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11034; Fri, 10 May 2002 07:36: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 HAA10998 for ; Fri, 10 May 2002 07:36:01 -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 HAA15137; Fri, 10 May 2002 07:35:48 -0400 (EDT) Message-Id: <200205101135.HAA15137@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: Fri, 10 May 2002 07:35:48 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-security-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 : Securing prioritised emergency traffic Author(s) : I. Brown Filename : draft-ietf-ieprep-security-00.txt Pages : 15 Date : 09-May-02 The Public Switched Telephone Network includes several mechanisms that increase the probability of completion for telephone calls made by authorised disaster relief personnel during emergencies such as hurricanes or terrorist attacks. This memo describes the security requirements of supporting this functionality in private and public IP networks, and how these requirements can be met using existing protocols. It also specifies which enhancements are necessary to these protocols to allow enhanced functionality such as roaming access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-security-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-security-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-security-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: <20020509124325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020509124325.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 15:18:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27548 for ; Mon, 13 May 2002 15:18:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08297; Mon, 13 May 2002 11:23: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 LAA08260 for ; Mon, 13 May 2002 11:23:08 -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 LAA15456 for ; Mon, 13 May 2002 11:22:56 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.0.8.125]) by gnat.inet.org (Postfix) with ESMTP id BF1AF67106 for ; Mon, 13 May 2002 11:53:12 -0400 (EDT) Date: Mon, 13 May 2002 11:22:33 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: RJ Atkinson To: IE Prep WG Content-Transfer-Encoding: 7bit In-Reply-To: <1bd.8e52d4.2a02a042@aol.com> Message-Id: <3FA728AF-6685-11D6-911A-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Subject: [Ieprep] Agenda for May 20 Interim Mtg ? 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 there a draft agenda for the IEprep Interim Meeting next Monday ? If yes, could someone either (re-)post it to the list (or send it to me unicast if its been posted and my mail system mislaid that note) ? I'm thinking the odds of a productive meeting are enhanced by having the agenda (and prerequisite I-D reading) done before the meeting starts. I could be wrong, of course. Thanks, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 15:33: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 PAA28378 for ; Mon, 13 May 2002 15:33:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06170; Mon, 13 May 2002 10:42: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 KAA06128 for ; Mon, 13 May 2002 10:42:27 -0400 (EDT) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13360 for ; Mon, 13 May 2002 10:42:11 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v32.5.) id l.d7.177e8510 (4387) for ; Mon, 13 May 2002 10:41:50 -0400 (EDT) Message-ID: Date: Mon, 13 May 2002 10:41:49 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_d7.177e8510.2a112aad_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] June 20 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 --part1_d7.177e8510.2a112aad_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, The specifics for the IEPREP interim meeting time/location: May 20 9AM - 2PM Sheraton Reston 11810 Sunrise Valley Drive Reston, VA 20191 +1 703-620-9000 From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building). From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above. Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov Questions on location, etc, please contact me. I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space. Ran Atkinson Greg Bain Fred Baker Cory Beard Hal Folts Janet Gunn Mike Morgan Stephen Perschau Mike Pierce Steve Silverman George Stanek If you have a presentation, please provide it in advance for those on the telephone conference. Mike Pierce --part1_d7.177e8510.2a112aad_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

The specifics for the IEPREP interim meeting time/location:

May 20 9AM - 2PM
Sheraton Reston
11810 Sunrise Valley Drive
Reston, VA 20191
+1 703-620-9000

From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building).

From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above.

Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov

Questions on location, etc, please contact me.

I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space.

Ran Atkinson
Greg Bain
Fred Baker
Cory Beard
Hal Folts
Janet Gunn
Mike Morgan
Stephen Perschau
Mike Pierce
Steve Silverman
George Stanek

If you have a presentation, please provide it in advance for those on the telephone conference.

Mike Pierce
--part1_d7.177e8510.2a112aad_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 15:36:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28532 for ; Mon, 13 May 2002 15:36:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06266; Mon, 13 May 2002 10:45: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 KAA06233 for ; Mon, 13 May 2002 10:45:29 -0400 (EDT) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13496 for ; Mon, 13 May 2002 10:45:17 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v32.5.) id l.9a.25776e7b (4226) for ; Mon, 13 May 2002 10:44:49 -0400 (EDT) Message-ID: <9a.25776e7b.2a112b60@aol.com> Date: Mon, 13 May 2002 10:44:48 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_9a.25776e7b.2a112b60_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] May 20th Interim Meeting (Really) 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_9a.25776e7b.2a112b60_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, Sorry about the previous e-mail with Subject: June 20. Too many meetings on my mind. The specifics for the IEPREP interim meeting time/location: May 20 9AM - 2PM Sheraton Reston 11810 Sunrise Valley Drive Reston, VA 20191 +1 703-620-9000 From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building). From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above. Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov Questions on location, etc, please contact me. I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space. Ran Atkinson Greg Bain Fred Baker Cory Beard Hal Folts Janet Gunn Mike Morgan Stephen Perschau Mike Pierce Steve Silverman George Stanek If you have a presentation, please provide it in advance for those on the telephone conference. Mike Pierce --part1_9a.25776e7b.2a112b60_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

Sorry about the previous e-mail with Subject: June 20. Too many meetings on my mind.

The specifics for the IEPREP interim meeting time/location:

May 20 9AM - 2PM
Sheraton Reston
11810 Sunrise Valley Drive
Reston, VA 20191
+1 703-620-9000

From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building).

From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above.

Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov


Questions on location, etc, please contact me.

I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space.

Ran Atkinson
Greg Bain
Fred Baker
Cory Beard
Hal Folts
Janet Gunn
Mike Morgan
Stephen Perschau
Mike Pierce
Steve Silverman
George Stanek


If you have a presentation, please provide it in advance for those on the telephone conference.

Mike Pierce
--part1_9a.25776e7b.2a112b60_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 15:36: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 PAA28563 for ; Mon, 13 May 2002 15:36: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 JAA02684; Mon, 13 May 2002 09:39: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 JAA02618 for ; Mon, 13 May 2002 09:39:50 -0400 (EDT) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09604 for ; Mon, 13 May 2002 09:39:36 -0400 (EDT) Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 10 May 2002 16:12:12 +0100 Received: from loki.ietf.org ([132.151.1.177]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 176BPU-00004z-00; Fri, 10 May 2002 15:30:16 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA14639 for ietf-123-outbound.04@ietf.org; Fri, 10 May 2002 10:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13208 for ; Fri, 10 May 2002 07:35:57 -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 HAA15137; Fri, 10 May 2002 07:35:48 -0400 (EDT) Message-Id: <200205101135.HAA15137@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: Fri, 10 May 2002 07:35:48 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-security-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 : Securing prioritised emergency traffic Author(s) : I. Brown Filename : draft-ietf-ieprep-security-00.txt Pages : 15 Date : 09-May-02 The Public Switched Telephone Network includes several mechanisms that increase the probability of completion for telephone calls made by authorised disaster relief personnel during emergencies such as hurricanes or terrorist attacks. This memo describes the security requirements of supporting this functionality in private and public IP networks, and how these requirements can be met using existing protocols. It also specifies which enhancements are necessary to these protocols to allow enhanced functionality such as roaming access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-security-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-security-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-security-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: <20020509124325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020509124325.I-D@ietf.org> --OtherAccess-- --NextPart-- . _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 20:30:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11332 for ; Mon, 13 May 2002 20:30:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06438; Mon, 13 May 2002 20:30: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 UAA06392 for ; Mon, 13 May 2002 20:29:57 -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 UAA11277 for ; Mon, 13 May 2002 20:29:42 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 20:29:54 -0400 Message-ID: From: "Folts, Harold" To: "'Mpierce1@aol.com'" , ieprep@ietf.org Subject: RE: [Ieprep] June 20 Interim Meeting Date: Mon, 13 May 2002 20:29:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FADE.776388A0" 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_01C1FADE.776388A0 Content-Type: text/plain; charset="iso-8859-1" I will be giving a short presentation on the revised white paper outlining the requirements for the IETF to address. I hope post the revised ID tomorrow. Hal -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Monday, May 13, 2002 10:42 AM To: ieprep@ietf.org Subject: [Ieprep] June 20 Interim Meeting To all, The specifics for the IEPREP interim meeting time/location: May 20 9AM - 2PM Sheraton Reston 11810 Sunrise Valley Drive Reston, VA 20191 +1 703-620-9000 From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building). From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above. Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov Questions on location, etc, please contact me. I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space. Ran Atkinson Greg Bain Fred Baker Cory Beard Hal Folts Janet Gunn Mike Morgan Stephen Perschau Mike Pierce Steve Silverman George Stanek If you have a presentation, please provide it in advance for those on the telephone conference. Mike Pierce ------_=_NextPart_001_01C1FADE.776388A0 Content-Type: text/html; charset="iso-8859-1"
I will be giving a short presentation on the revised white paper outlining the requirements for the IETF to address. I hope post the revised ID tomorrow.
 
Hal
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Monday, May 13, 2002 10:42 AM
To: ieprep@ietf.org
Subject: [Ieprep] June 20 Interim Meeting

To all,

The specifics for the IEPREP interim meeting time/location:

May 20 9AM - 2PM
Sheraton Reston
11810 Sunrise Valley Drive
Reston, VA 20191
+1 703-620-9000

From Dulles airport, take Dulles Airport Access road east (toward Washington) and switch over to the toll road to the Reston Parkway, exit 12 (about 4 miles). Exit south and go 1/2 mile, then left at first stop light (Sunrise Valley Drive). Hotel will be on your left adjacent to the Reston International Center (tall building).

From DC, take Dulles Toll Road, highway 267 (not the Airport Access Road). Exit Reston Parkway as above.

Arrangements have been made for a telephone conference. If you plan to participate via the telephone, please notify Hall Folts at foltsh@ncs.gov

Questions on location, etc, please contact me.

I have received confirmations from the following that they plan to attend in person. Any others, please notify me of your intention so that we can ensure proper space.

Ran Atkinson
Greg Bain
Fred Baker
Cory Beard
Hal Folts
Janet Gunn
Mike Morgan
Stephen Perschau
Mike Pierce
Steve Silverman
George Stanek

If you have a presentation, please provide it in advance for those on the telephone conference.

Mike Pierce
------_=_NextPart_001_01C1FADE.776388A0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 13 21:11:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13022 for ; Mon, 13 May 2002 21:11: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 VAA08484; Mon, 13 May 2002 21: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 VAA08446 for ; Mon, 13 May 2002 21:01:30 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12697 for ; Mon, 13 May 2002 21:01:16 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4E10nuG013760; Mon, 13 May 2002 18:00:50 -0700 (PDT) Message-Id: <5.1.0.14.2.20020513175942.01ca5a60@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 May 2002 18:00:48 -0700 To: rja@inet.org From: Fred Baker Subject: Fwd: Re: [Ieprep] IEPREP Interim Meeting? Cc: ieprep@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 This is what I posted to the list for an agenda. >Date: Fri, 26 Apr 2002 19:23:13 -0400 >To: "'ieprep@ietf.org'" >From: Fred Baker >Subject: Re: [Ieprep] IEPREP Interim Meeting? > >At 05:34 PM 4/24/2002 -0400, Gunn, Janet NE wrote: >>The minutes from the IEPREP WG meting say that an interim meeting will be >>held in May or June. Have there been any developments on date or locations? > >DISA (Don Choi) has offered to host a meeting in Washington DC on May 20, >from 9:00 to 2:00. I'm technically a little late announcing that - I >should have done so by April 20, for various reasons including travel >issues. My lame excuse is that I visited DISA on Wednesday, and I wanted >to actually announce the meeting subsequent to said visit. My reason for >calling an interim is partly that I think we probably have enough on the >table to have a useful discussion, and can lay out a road map in that >meeting towards a consensus call on final documents agreed to in Yokohama. > > I would like, specifically, to discuss: > > - A presentation from DISA (proposed by Don Choi) clarifying DISA issues > and requirements > - Henning Schulzrin's SIP MLPP and e911 requirements > - James Polk's SIP response to that draft > - Cory Beard's document > - an update to Hal's requirements document > - any changes that Ken has made to his framework proposal, and the > future of that proposal > - direction for the BCP(s), including a table of contents and > solicitation of text for it > >And I would like to further discuss things that have been of interest in >on the mailing list. We probably also have other things to discuss; folks >who want to have a particular discussion should send me a note privately >or post to the list. > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 11:46: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 LAA24103 for ; Tue, 14 May 2002 11:46: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 LAA20749; Tue, 14 May 2002 11:43: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 LAA20710 for ; Tue, 14 May 2002 11:43:53 -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 LAA24014 for ; Tue, 14 May 2002 11:43:40 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 14 May 2002 16:43:47 +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: Tue, 14 May 2002 16:43:46 +0100 Message-ID: <1473.1021391026@cs.ucl.ac.uk> From: Ken Carlberg Subject: [Ieprep] Framework draft, v1 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 an updated version of the Framework draft has been submitted to the internet-drafts repository. it will probably take a few days for it to go through the system, so in the meantime, folks can get a copy at: http://www.cs.ucl.ac.uk/staff/k.carlberg/tmp/draft-ietf-ieprep-framework-01 .txt changes from the previous version of the draft presented in Minneapolis include: - incorporating clarifications about GETS sent by Dennis Berg - incorporating comments from the Minneapolis-IETF meeting - Added Appendix A that describes GTPS, the emergency phone scheme used in the UK - Added Appendix B describing related work being done in SG16 in adding labels in call setup messages of H.323 What still needs to be done is: - additional input for Appendix B to describe related work being done by SG11, and T1S1 Sorry about the late submission with respect to the interim meeting. Most of the changes (outside of the appendix) are minor. Ian Brown will give a brief presentation on these changes at the meeting next monday. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 12:58: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 MAA26372 for ; Tue, 14 May 2002 12:58: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 HAA01310; Tue, 14 May 2002 07:56: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 HAA01279 for ; Tue, 14 May 2002 07:56:11 -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 HAA13957 for ; Tue, 14 May 2002 07:55:58 -0400 (EDT) Message-ID: <20020514115609.48227.qmail@web20806.mail.yahoo.com> Received: from [134.193.6.40] by web20806.mail.yahoo.com via HTTP; Tue, 14 May 2002 04:56:09 PDT Date: Tue, 14 May 2002 04:56:09 -0700 (PDT) From: senthil ayyasamy To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] Any impact from the earthquake in CA? Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Hi all, I think internet is working fine except for some telephone clogging.I am not aware of any flash crowd problems with newsites.I am little curious to know the number of GETS call and the role of FEMA & GETS in rescue work . - Senthil --- Joe wrote: > From: "Joe" > To: > Subject: Re: Any impact from the 5.2 earthquake in > Gilroy CA? > Date: Tue, 14 May 2002 02:09:53 -0700 > > Well, apparently XO doesn't care about > Their customers as we've been down from > one site for over 4 hours with a DS3 feed. > > > Oh well... > > -Joe > > > Joe wrote: > > > Just wondering if anyone else saw loss of > service durng this > quake. Ours was Aprx. 30 mins. > > -Joe > > > > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 13:04:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26563 for ; Tue, 14 May 2002 13:04: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 DAA13030; Tue, 14 May 2002 03:34: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 DAA12997 for ; Tue, 14 May 2002 03:34:15 -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 DAA06820 for ; Tue, 14 May 2002 03:34:02 -0400 (EDT) Message-ID: <20020514073414.92052.qmail@web20806.mail.yahoo.com> Received: from [134.193.6.40] by web20806.mail.yahoo.com via HTTP; Tue, 14 May 2002 00:34:14 PDT Date: Tue, 14 May 2002 00:34:14 -0700 (PDT) From: senthil ayyasamy To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California 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 Did GETs got any call??? I think internet is fine.I could reach all newsites except some Govt sites. --- Roy wrote: > Date: Mon, 13 May 2002 23:37:51 -0700 > From: Roy > To: nanog@nanog.org > Subject: Re: 5.2 Earthquake in Northern California > > > > I live about 3 mi from the epicenter and our main > NOC is about 9 miles. As far > as I can tell, we didn't even drop a packet. > > Some stuff fell of the shelves and the cats panicked > as expected. > > Reference my previous note, Broadwing called about > 10 minutes after the quake and > told me they had isolated the problem and expected > repair within the hour. It > was fixed on schedule so the phone people were BAU. > > John Kinsella wrote: > > > There's something on sfgate.com about phone > service being out in SJ? I > > couldn't call out on cingular but could receive > calls. > > > > John > > > > On Mon, May 13, 2002 at 10:25:19PM -0700, Sameer > R. Manek wrote: > > > > > > We just had a 5.2 magnitude earthquake at 10pm, > it was centered SW of > > > Gilroy, CA. Cingular's network was peaked for a > few minutes after the call, > > > presumably as everyone called friends/family. No > reports of phone/power > > > outages yet. > > > > > > Sameer > > > > > > > ------------------------------------------------------------------------- > > > Sameer R. Manek > Email: manek@ghur.net > > > "What one has not experienced, one will never > understand in print." > > > --Isadora Duncan > > > > ------------------------------------------------------------------------- > > > > > > > ===== 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!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 13:59:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28519 for ; Tue, 14 May 2002 13:59:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05831; Tue, 14 May 2002 13:59: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 NAA05797 for ; Tue, 14 May 2002 13:58:55 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28502 for ; Tue, 14 May 2002 13:58:37 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-16.cisco.com [128.107.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4EHwBuG009364; Tue, 14 May 2002 10:58:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20020514105739.01bbe918@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 May 2002 10:58:14 -0700 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] Any impact from the earthquake in CA? Cc: ieprep@ietf.org In-Reply-To: <20020514115609.48227.qmail@web20806.mail.yahoo.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:56 AM 5/14/2002 -0700, senthil ayyasamy wrote: >I think internet is working fine except for some >telephone clogging.I am not aware of any flash crowd >problems with newsites.I am little curious to know the >number of GETS call and the role of FEMA & GETS in >rescue work . there was an earthquake? I didn't notice in Santa Barbara or San Jose. Maybe it happened while I was flying? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 14:21: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 OAA29158 for ; Tue, 14 May 2002 14:21: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 OAA06946; Tue, 14 May 2002 14:12: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 OAA06900 for ; Tue, 14 May 2002 14:12:49 -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 OAA28917 for ; Tue, 14 May 2002 14:12:35 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 14:12:10 -0400 Message-ID: From: "Gunn, Janet NE" To: "'senthil ayyasamy'" , ieprep@ietf.org Subject: RE: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Date: Tue, 14 May 2002 14:11:59 -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 am more involved in the "future functionality" of GETS than the current operations, but I will see what I can come up with. Janet -----Original Message----- From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] Sent: Tuesday, May 14, 2002 3:34 AM To: ieprep@ietf.org Subject: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Did GETs got any call??? I think internet is fine.I could reach all newsites except some Govt sites. --- Roy wrote: > Date: Mon, 13 May 2002 23:37:51 -0700 > From: Roy > To: nanog@nanog.org > Subject: Re: 5.2 Earthquake in Northern California > > > > I live about 3 mi from the epicenter and our main > NOC is about 9 miles. As far > as I can tell, we didn't even drop a packet. > > Some stuff fell of the shelves and the cats panicked > as expected. > > Reference my previous note, Broadwing called about > 10 minutes after the quake and > told me they had isolated the problem and expected > repair within the hour. It > was fixed on schedule so the phone people were BAU. > > John Kinsella wrote: > > > There's something on sfgate.com about phone > service being out in SJ? I > > couldn't call out on cingular but could receive > calls. > > > > John > > > > On Mon, May 13, 2002 at 10:25:19PM -0700, Sameer > R. Manek wrote: > > > > > > We just had a 5.2 magnitude earthquake at 10pm, > it was centered SW of > > > Gilroy, CA. Cingular's network was peaked for a > few minutes after the call, > > > presumably as everyone called friends/family. No > reports of phone/power > > > outages yet. > > > > > > Sameer > > > > > > > ------------------------------------------------------------------------- > > > Sameer R. Manek > Email: manek@ghur.net > > > "What one has not experienced, one will never > understand in print." > > > --Isadora Duncan > > > > ------------------------------------------------------------------------- > > > > > > > ===== 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!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.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 Tue May 14 14: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 OAA00323 for ; Tue, 14 May 2002 14: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 OAA10479; Tue, 14 May 2002 14:48: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 OAA10448 for ; Tue, 14 May 2002 14:48:19 -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 OAA00263 for ; Tue, 14 May 2002 14:48:04 -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 LAA25307; Tue, 14 May 2002 11:45:52 -0700 (PDT) Message-Id: <4.1.20020514134404.015b01d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 14 May 2002 13:45:46 -0500 To: Fred Baker , senthil ayyasamy From: "James M. Polk" Subject: Re: [Ieprep] Any impact from the earthquake in CA? Cc: ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020514105739.01bbe918@mira-sjcm-4.cisco.com> References: <20020514115609.48227.qmail@web20806.mail.yahoo.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 It was in the late evening -- San Francisco felt it, as did the fans at the Compaq Center during the 3rd period of the San Jose-Colorado NHL game... registered 5.2 At 10:58 AM 5/14/2002 -0700, Fred Baker wrote: >At 04:56 AM 5/14/2002 -0700, senthil ayyasamy wrote: >>I think internet is working fine except for some >>telephone clogging.I am not aware of any flash crowd >>problems with newsites.I am little curious to know the >>number of GETS call and the role of FEMA & GETS in >>rescue work . > >there was an earthquake? I didn't notice in Santa Barbara or San Jose. >Maybe it happened while I was flying? > > >_______________________________________________ >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 May 14 15:40: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 PAA02682 for ; Tue, 14 May 2002 15:40: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 OAA10980; Tue, 14 May 2002 14:56:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10904 for ; Tue, 14 May 2002 14:56:01 -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 OAA00620 for ; Tue, 14 May 2002 14:55:47 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 14:55:17 -0400 Message-ID: From: "Gunn, Janet NE" To: "Gunn, Janet NE" , "'senthil ayyasamy'" , ieprep@ietf.org Subject: RE: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Date: Tue, 14 May 2002 14:55:07 -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 been told that the earliest I will be able to get any info (since this is essentially just an "I am curious" request) is 11AM tomorrow. I will forward the info when I get it. Janet -----Original Message----- From: Gunn, Janet NE Sent: Tuesday, May 14, 2002 2:12 PM To: 'senthil ayyasamy'; ieprep@ietf.org Subject: RE: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California I am more involved in the "future functionality" of GETS than the current operations, but I will see what I can come up with. Janet -----Original Message----- From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] Sent: Tuesday, May 14, 2002 3:34 AM To: ieprep@ietf.org Subject: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Did GETs got any call??? I think internet is fine.I could reach all newsites except some Govt sites. --- Roy wrote: > Date: Mon, 13 May 2002 23:37:51 -0700 > From: Roy > To: nanog@nanog.org > Subject: Re: 5.2 Earthquake in Northern California > > > > I live about 3 mi from the epicenter and our main > NOC is about 9 miles. As far > as I can tell, we didn't even drop a packet. > > Some stuff fell of the shelves and the cats panicked > as expected. > > Reference my previous note, Broadwing called about > 10 minutes after the quake and > told me they had isolated the problem and expected > repair within the hour. It > was fixed on schedule so the phone people were BAU. > > John Kinsella wrote: > > > There's something on sfgate.com about phone > service being out in SJ? I > > couldn't call out on cingular but could receive > calls. > > > > John > > > > On Mon, May 13, 2002 at 10:25:19PM -0700, Sameer > R. Manek wrote: > > > > > > We just had a 5.2 magnitude earthquake at 10pm, > it was centered SW of > > > Gilroy, CA. Cingular's network was peaked for a > few minutes after the call, > > > presumably as everyone called friends/family. No > reports of phone/power > > > outages yet. > > > > > > Sameer > > > > > > > ------------------------------------------------------------------------- > > > Sameer R. Manek > Email: manek@ghur.net > > > "What one has not experienced, one will never > understand in print." > > > --Isadora Duncan > > > > ------------------------------------------------------------------------- > > > > > > > ===== 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!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.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 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 15:52: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 PAA03257 for ; Tue, 14 May 2002 15:52: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 PAA16229; Tue, 14 May 2002 15:52: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 PAA16191 for ; Tue, 14 May 2002 15:52:19 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03240 for ; Tue, 14 May 2002 15:52:05 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-16.cisco.com [128.107.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4EJpeuG020834; Tue, 14 May 2002 12:51:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20020514124816.0480ff88@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 May 2002 12:51:43 -0700 To: "James M. Polk" From: Fred Baker Subject: Re: [Ieprep] Any impact from the earthquake in CA? Cc: senthil ayyasamy , ieprep@ietf.org In-Reply-To: <4.1.20020514134404.015b01d0@localhost> References: <5.1.0.14.2.20020514105739.01bbe918@mira-sjcm-4.cisco.com> <20020514115609.48227.qmail@web20806.mail.yahoo.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 01:45 PM 5/14/2002 -0500, James M. Polk wrote: >It was in the late evening -- San Francisco felt it, as did the fans at the >Compaq Center during the 3rd period of the San Jose-Colorado NHL game... >registered 5.2 Oh, 5.2. To compare it to tornados, it's a stiff wind. To compare it to blizzards, it's a heavy snow. I'm sorry, I have lived in California far too long. I don't notice anything below about 6.0. :^) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 15:54:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03405 for ; Tue, 14 May 2002 15:54: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 PAA16881; Tue, 14 May 2002 15:54: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 PAA16843 for ; Tue, 14 May 2002 15:54:44 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03369 for ; Tue, 14 May 2002 15:54:26 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 177iNb-000653-00 for ieprep@ietf.org; Tue, 14 May 2002 15:54:39 -0400 Date: Tue, 14 May 2002 15:54:39 -0400 (EDT) From: Sean Donelan To: ieprep@ietf.org Subject: Re: [Ieprep] Any impact from the earthquake in CA? In-Reply-To: <5.1.0.14.2.20020514105739.01bbe918@mira-sjcm-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Tue, 14 May 2002, Fred Baker wrote: > At 04:56 AM 5/14/2002 -0700, senthil ayyasamy wrote: > >I think internet is working fine except for some > >telephone clogging.I am not aware of any flash crowd > >problems with newsites.I am little curious to know the > >number of GETS call and the role of FEMA & GETS in > >rescue work . > > there was an earthquake? I didn't notice in Santa Barbara or San Jose. > Maybe it happened while I was flying? At 5.2 it was in the medium level of earthquakes. Strong enough to get everyone's attention, but it didn't appear to have caused any severe damage. There have been several aftershocks. A residential fire caused by an overturned water heater, a broken water main, San Jose Mercury News reported that Pacific Bell telephone service was briefly disrupted in parts of Santa Clara. I haven't seen an FCC outage report on the FCC's web site yet. The 11 O'clock news broadcasts last night mostly consisted of reporters saying there was no major damage. Nothing Internet related to report. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 16:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03733 for ; Tue, 14 May 2002 16:01:56 -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 QAA18091; Tue, 14 May 2002 16:01: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 QAA18054 for ; Tue, 14 May 2002 16:01:36 -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 QAA03699 for ; Tue, 14 May 2002 16:01:21 -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 NAA15826; Tue, 14 May 2002 13:01:02 -0700 (PDT) Message-Id: <4.1.20020514150026.015284b0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 14 May 2002 15:00:56 -0500 To: Fred Baker From: "James M. Polk" Subject: Re: [Ieprep] Any impact from the earthquake in CA? Cc: senthil ayyasamy , ieprep@ietf.org In-Reply-To: <5.1.0.14.2.20020514124816.0480ff88@mira-sjcm-4.cisco.com> References: <4.1.20020514134404.015b01d0@localhost> <5.1.0.14.2.20020514105739.01bbe918@mira-sjcm-4.cisco.com> <20020514115609.48227.qmail@web20806.mail.yahoo.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 At 12:51 PM 5/14/2002 -0700, Fred Baker wrote: >At 01:45 PM 5/14/2002 -0500, James M. Polk wrote: >>It was in the late evening -- San Francisco felt it, as did the fans at the >>Compaq Center during the 3rd period of the San Jose-Colorado NHL game... >>registered 5.2 > >Oh, 5.2. To compare it to tornados, it's a stiff wind. To compare it to >blizzards, it's a heavy snow. > >I'm sorry, I have lived in California far too long. I don't notice anything >below about 6.0. Amen > >:^) > ************************************* "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 May 14 17:47: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 RAA08534 for ; Tue, 14 May 2002 17:47: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 RAA27098; Tue, 14 May 2002 17:46: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 RAA27059 for ; Tue, 14 May 2002 17:46:42 -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 RAA08507 for ; Tue, 14 May 2002 17:46:29 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4453); Tue, 14 May 2002 16:46:41 -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="iso-8859-1" Date: Tue, 14 May 2002 16:46:41 -0500 Message-ID: Thread-Topic: draft-beard-ieprep-requirements-00.txt Thread-Index: AcH7kCk70d4mKmc2EdaHNwBQBJSk2gAADe4A From: "Beard, Cory" To: X-OriginalArrivalTime: 14 May 2002 21:46:41.0352 (UTC) FILETIME=[D52E2C80:01C1FB90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA27060 Subject: [Ieprep] draft-beard-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: 8bit I have just submitted the following individual submission for an Internet Draft. Title : Network Requirements for Internet Emergency Preparedness Services Author(s) : C. Beard Filename : draft-beard-ieprep-requirements-00.txt Pages : 12 Date : Abstract: 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 template from which an emergency service can be negotiated and provides a set of requirements that should be met for acceptable emergency communication services. The focus here is on network requirements, rather than requirements for particular applications. The requirements are general and are intended to provide wide latitude in implementation options for service providers. Before it makes it through the system, it can be viewed at: http://unofficial.umkc.edu/beardc/draft-beard-ieprep-requirements-00.txt Thanks very much, Cory Beard University of Missouri-Kansas City _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 14 19:18: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 TAA11507 for ; Tue, 14 May 2002 19:18: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 TAA01633; Tue, 14 May 2002 19: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 TAA01595 for ; Tue, 14 May 2002 19:17:44 -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 TAA11470 for ; Tue, 14 May 2002 19:17:30 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 19:17:43 -0400 Message-ID: From: "Folts, Harold" To: "ieprep List (E-mail)" Date: Tue, 14 May 2002 19:17:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FB9D.8B42E9A0" Subject: [Ieprep] New Requirements ID 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_000_01C1FB9D.8B42E9A0 Content-Type: text/plain; charset="iso-8859-1" I have submitted a new ID on ieprep requirements for discussion at Monday's meeting. you can get a copy at: ftp://iepscheme.net/pub/ieps/docs/draft-folts-ieprep-requirements-00.txt Hal ------_=_NextPart_000_01C1FB9D.8B42E9A0 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C1FB9D.8B42E9A0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 15 03:37: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 DAA20677 for ; Wed, 15 May 2002 03:37: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 CAA14392; Wed, 15 May 2002 02:31: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 CAA14322 for ; Wed, 15 May 2002 02:31:19 -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 CAA17611 for ; Wed, 15 May 2002 02:31:04 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 02:31:16 -0400 Message-ID: From: "Folts, Harold" To: "'senthil ayyasamy'" , ieprep@ietf.org Subject: RE: [Ieprep] Any impact from the earthquake in CA? Date: Wed, 15 May 2002 02:31:14 -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 > -----Original Message----- > From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] > Sent: Tuesday, May 14, 2002 7:56 AM > To: ieprep@ietf.org > Subject: [Ieprep] Any impact from the earthquake in CA? > > > Hi all, > I think internet is working fine except for some > telephone clogging.I am not aware of any flash crowd > problems with newsites.I am little curious to know the > number of GETS call and the role of FEMA & GETS in > rescue work . First I suggest you read my new ID, which will provide the correct picture of what we are trying to accomplish ftp://iepscheme.net/pub/ieps/docs/draft-folts-ieprep-requirements-00.txt FEMA is one of many authorized users of GETS. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 15 07:21: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 HAA26143 for ; Wed, 15 May 2002 07:21: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 HAA05795; Wed, 15 May 2002 07:11: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 HAA05741 for ; Wed, 15 May 2002 07:11:53 -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 HAA25704; Wed, 15 May 2002 07:11:38 -0400 (EDT) Message-Id: <200205151111.HAA25704@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, 15 May 2002 07:11:37 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-01.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-01.txt Pages : 30 Date : 14-May-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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ieprep-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020514141903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020514141903.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 May 15 08:55: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 IAA01046 for ; Wed, 15 May 2002 08:55: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 IAA13698; Wed, 15 May 2002 08:54: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 IAA13586 for ; Wed, 15 May 2002 08:54: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 IAA00873 for ; Wed, 15 May 2002 08:53:55 -0400 (EDT) Received: from async71-16.nas.onetel.net.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Wed, 15 May 2002 13:54:03 +0100 From: Ian Brown To: ieprep Date: Wed, 15 May 2002 13:54:39 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Ieprep] Network Monoculture: Diversity, Survivability, and the Profitability of Internet Commerce 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 Anyone around Boston might find this interesting... -- The Digital Commerce Society of Boston Presents John S. Quarterman Founder, CTO Matrix NetSystems, Inc. Network Monoculture: Diversity, Survivability, and the Profitablity of Internet Commerce Tuesday, June 4th, 2002 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Monoculture is harmful for ecosystems or markets. This talk will illustrate performance effects on the Internet caused by natural (hurricane, earthquake) and unnatural (routing flap, cable cut, building damage) disasters. Measuring performance of the Internet can enable price differentiation, asset and liability management, and speed Internet evolution by providing it a business model. John S. Quarterman wrote The Matrix, a comprehensive book on the history, technology, and people of computer networks worldwide, as well as six other books. He is a founder and Chief Technology Officer of Matrix NetSystems, which is the most experienced Internet analyst, established as Matrix Information and Directory Services (MIDS) in 1990, and since 1998 an Internet startup with Internet performance products. Quarterman published the first maps of the whole Internet; conducted the first Internet Demographic Survey; and started the first continuing series of performance data about the entire Internet in 1993, on the web since 1995 in the Internet Weather Report, and also visible as average.matrixnetsystems.com, plus comparisons of ISPs visible as ratings.matrixnetsystems.com. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, June 4th, 2002, from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, on One Federal Street. Luncheon seats are $49.00. The Harvard Club has relaxed its dress code, which is now "business casual", meaning no sneakers or jeans. Fair warning: since we purchase these luncheons in advance, we will be unable to refund the price of your meal if the Club finds you in violation of what's left of its dress code. In addition, since the "dot-bomb", the suit-probability in the main dining room has been asymptotically approaching unity, and we should probably dress accordingly. :-). We need to receive a company check, or money order, (or, if we know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, June 1st, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will be returned. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston", in the amount of $49.00. Please include your e-mail address so that we can send you a confirmation If anyone has questions, or has a problem with these arrangements (we've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Upcoming speakers for DCSB are: August 6 Donald Eastlake XML Security As you can see, we are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, are a principal in digital commerce, and would like to make a presentation to the Society, please send e-mail to the DCSB Program Committee, care of Robert Hettinga, , and we'll send you a call for speakers. For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to . We look forward to seeing you there! _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 15 12:56: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 MAA13150 for ; Wed, 15 May 2002 12:56: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 MAA11633; Wed, 15 May 2002 12:49: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 MAA11595 for ; Wed, 15 May 2002 12:49: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 MAA12933 for ; Wed, 15 May 2002 12:49:04 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:48:32 -0400 Message-ID: From: "Gunn, Janet NE" To: "Gunn, Janet NE" , "'senthil ayyasamy'" , ieprep@ietf.org Subject: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Date: Wed, 15 May 2002 12:48:22 -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 Apparently, this event did not trigger a lot of GETS activity. "As you know yesterdays 5.2 earthquake near Gilroy, CA was an "event" However I see no unusual GETS activity whatso ever The daily numbers of originating and incoming were actually about the same or slightly less then usual for a given day attached here is the 115 isolated by clli and 30 minute interval of the near 200 or so calls of which only 7 came into the state" Janet -----Original Message----- From: Gunn, Janet NE Sent: Tuesday, May 14, 2002 2:12 PM To: 'senthil ayyasamy'; ieprep@ietf.org Subject: RE: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California I am more involved in the "future functionality" of GETS than the current operations, but I will see what I can come up with. Janet -----Original Message----- From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] Sent: Tuesday, May 14, 2002 3:34 AM To: ieprep@ietf.org Subject: [Ieprep] Fwd: Re: 5.2 Earthquake in Northern California Did GETs got any call??? I think internet is fine.I could reach all newsites except some Govt sites. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 16 12:43:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01489 for ; Thu, 16 May 2002 12:43:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26758; Thu, 16 May 2002 12:41: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 MAA26723 for ; Thu, 16 May 2002 12:41:55 -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 MAA01412 for ; Thu, 16 May 2002 12:41:40 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4453); Thu, 16 May 2002 11:41:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1FCF8.96439662" Date: Thu, 16 May 2002 11:41:54 -0500 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-beard-ieprep-requirements-00.txt Thread-Index: AcH82BuDzmAxY6lMTpGCtVrV+jwalwAIG/5Q From: "Beard, Cory" To: X-OriginalArrivalTime: 16 May 2002 16:41:54.0682 (UTC) FILETIME=[964D45A0:01C1FCF8] Subject: [Ieprep] I-D ACTION:draft-beard-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1FCF8.96439662 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Network Requirements for Internet Emergency=20 Preparedness Services Author(s) : C. Beard Filename : draft-beard-ieprep-requirements-00.txt Pages : 12 Date : 15-May-02 =09 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 template from which an emergency service can be negotiated and provides a set of requirements that should be met for acceptable emergency communication services. The focus here is on network requirements, rather than requirements for particular applications. The requirements are general 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-beard-ieprep-requirements-00.tx= t To remove yourself from the IETF Announcement list, send a message to=20 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-beard-ieprep-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-beard-ieprep-requirements-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C1FCF8.96439662 Content-Type: application/octet-stream; name="ATT212592.TXT" Content-Description: ATT212592.TXT Content-Disposition: attachment; filename="ATT212592.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyMDUxNTEyMDgyNS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iZWFyZC1pZXByZXAtcmVx dWlyZW1lbnRzLTAwLnR4dA0K ------_=_NextPart_001_01C1FCF8.96439662 Content-Type: application/octet-stream; name="draft-beard-ieprep-requirements-00.URL" Content-Description: draft-beard-ieprep-requirements-00.URL Content-Disposition: attachment; filename="draft-beard-ieprep-requirements-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1iZWFyZC1pZXByZXAtcmVxdWlyZW1lbnRzLTAwLnR4dA0K ------_=_NextPart_001_01C1FCF8.96439662-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri May 17 19:17: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 TAA11847 for ; Fri, 17 May 2002 19:17: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 TAA09770; Fri, 17 May 2002 19:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09738 for ; Fri, 17 May 2002 19:16:40 -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 TAA11830 for ; Fri, 17 May 2002 19:16:23 -0400 (EDT) Message-ID: <20020517231638.76115.qmail@web20802.mail.yahoo.com> Received: from [134.193.6.52] by web20802.mail.yahoo.com via HTTP; Fri, 17 May 2002 16:16:38 PDT Date: Fri, 17 May 2002 16:16:38 -0700 (PDT) From: senthil ayyasamy Subject: RE: [Ieprep] Any impact from the earthquake in CA? To: "Folts, Harold" , ieprep@ietf.org 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 think internet is working fine except for some > > telephone clogging.I am not aware of any flash > crowd > > problems with newsites.I am little curious to know > the > > number of GETS call and the role of FEMA & GETS > in > > rescue work . > > First I suggest you read my new ID Hal, I have read both the older and new version of your draft. Some of the requirements specified in the draft are more particular to telephone networks. The approach of the draft seems to be more towards connection-oriented networks unlike Internet. Eg: *2.A.5.Completion to destination * Please correct me if I am wrong. The connectionless nature of the Internet gives only probability of acceptance of a connection & hence completion to destination can never be gauranteed. This is due to the *control at the end points* nature of Internet unlike the telephone network. >which will > provide the correct picture > of what we are trying to accomplish Your draft doesn't answer my question. My question was more related to the number of GETS calls and FEMA's role in the miniscule earthquake. I was just curious though understand the answer was that nothing happened. > FEMA is one of many authorized users of GETS. FEMA provides ad-hoc management something like office in a box. Your draft could eloborate more on requirements for supporting GETS in the Internet (Fred mentioned your draft as U.S govt's requirements). Also, your draft talks about mobile radio, dedicated satellite systems, telecommunication infrastructure, etc. In some previous discussion, work in MESA and EMTEL of ETSI about supporting emergency in wireless, satellite systems, etc. was mentioned. It would be better if you advise us on some of their goals and relevance to IEPREP. Thanks in advance, -Senthil __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat May 18 11:04: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 LAA16612 for ; Sat, 18 May 2002 11:04: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 LAA17078; Sat, 18 May 2002 11:04: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 LAA17044 for ; Sat, 18 May 2002 11:04:13 -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 LAA16594 for ; Sat, 18 May 2002 11:03:56 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Sat, 18 May 2002 11:04:11 -0400 Message-ID: From: "Folts, Harold" To: "Ieprep List (ieprep@ietf.org)" Date: Sat, 18 May 2002 11:04:09 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FE7D.43754310" Subject: [Ieprep] Re: ieprep Telecom Bridge Monday 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_01C1FE7D.43754310 Content-Type: text/plain Just to confirm the telecom bridge for the meeting Monday: Tel # - 888 820-8951 Pass Code - 25508 Leader - Hal Folts If you have any difficulty, please call me at 703 618-6592. I might have to add extra ports on the bridge if we get more calls than planned. Hal ------_=_NextPart_001_01C1FE7D.43754310 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: ieprep Telecom Bridge Monday

Just to confirm the telecom bridge for = the meeting Monday:

Tel # - 888 820-8951
Pass Code -  25508   = Leader - Hal Folts

If you have any difficulty, please = call me at 703 618-6592. I might have to add extra ports on the bridge = if we get more calls than planned.

Hal

------_=_NextPart_001_01C1FE7D.43754310-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat May 18 18:33: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 SAA02011 for ; Sat, 18 May 2002 18:33:36 -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 SAA00850; Sat, 18 May 2002 18:32: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 SAA00813 for ; Sat, 18 May 2002 18:32:40 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01980 for ; Sat, 18 May 2002 18:32:22 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 179Ckb-0001Bb-00 for ieprep@ietf.org; Sat, 18 May 2002 18:32:33 -0400 Date: Sat, 18 May 2002 18:32:33 -0400 (EDT) From: Sean Donelan To: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Wed, 15 May 2002, Gunn, Janet NE wrote: > Apparently, this event did not trigger a lot of GETS activity. > > "As you know yesterdays 5.2 earthquake near Gilroy, CA was an "event" > However I see no unusual GETS activity whatso ever > The daily numbers of originating and incoming were actually about the same > or slightly less then usual for a given day > attached here is the 115 isolated by clli and 30 minute interval of the > near 200 or so calls of which only 7 came into the state" I'm confused. Was the public telephone network congested to require the use of GETS at all on Tuesday? Were normal calls being blocked on Tuesday, which required designated users to invoke GETS special handling? The only FCC outage report on Tuesday was in Norfolk Virginia, all inter-office, long distance and 9-1-1 service was out for 50,000+ people due to yet another DACS failure. Shouldn't the number of GETS calls be zero, except during a massive telephone problem? If a GETS-like service is introduced into the Internet, is this just during "emergencies" or is the government expecting to use GETS all the time, even when the Internet is functioning normally, just to shove in front of the line? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 02:49: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 CAA26629 for ; Sun, 19 May 2002 02:49: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 CAA21346; Sun, 19 May 2002 02:46: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 CAA21317 for ; Sun, 19 May 2002 02:46:31 -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 CAA26523 for ; Sun, 19 May 2002 02:46:13 -0400 (EDT) Received: from async41-17.nas.onetel.net.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Sun, 19 May 2002 07:36:43 +0100 From: Ian Brown To: ieprep Date: Sun, 19 May 2002 07:37:22 +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] Dirigibles get the call: Uncle Sam wants you 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 Friday, May 17, 2002 By MIKE BARBER SEATTLE POST-INTELLIGENCER REPORTER Dirigibles -- massive flying machines that went the way of the mammoth a half-century ago -- are being resurrected as high-tech weapons in the war on terror. Twice as big as a jumbo jet and soaring twice as high, they may soon be deployed to guard Canada and the United States, scanning for intruders on the Pacific Northwest's long coastline and international border... The aerospace industry has been talking about airships for years. In addition to defense implications, high-flying airships might be used for resource management, disaster communications and weather monitoring... http://seattlepi.nwsource.com/local/70823_dirigibles17.shtml _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 05:05: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 FAA29799 for ; Sun, 19 May 2002 05:05: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 EAA25094; Sun, 19 May 2002 04:50: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 EAA25060 for ; Sun, 19 May 2002 04:50:23 -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 EAA29529 for ; Sun, 19 May 2002 04:50:07 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 19 May 2002 09:50:08 +0100 To: Sean Donelan cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-reply-to: Your message of "Sat, 18 May 2002 18:32:33 EDT." Date: Sun, 19 May 2002 09:50:07 +0100 Message-ID: <10309.1021798207@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 > > attached here is the 115 isolated by clli and 30 minute interval of the > > near 200 or so calls of which only 7 came into the state" > > I'm confused. Was the public telephone network congested to require > the use of GETS at all on Tuesday? Were normal calls being blocked on > Tuesday, which required designated users to invoke GETS special handling? > The only FCC outage report on Tuesday was in Norfolk Virginia, all > inter-office, long distance and 9-1-1 service was out for 50,000+ people > due to yet another DACS failure. > > Shouldn't the number of GETS calls be zero, except during a massive > telephone problem? so, lets see, if we look at the numbers there is (roughly) 50K+ authorized users of GETS....and yet 200 calls were made. not bad when you consider that some percentage are testing for service (could be govenrmnet OR carrier technicians) and/or checking for fraud -- which i'm sure you're aware is common place action to take. and then the rest are probably officials making an emergency call. actually, quite a restrained number in my opinion.... > If a GETS-like service is introduced into the Internet, is this just > during "emergencies" or is the government expecting to use GETS all the > time, even when the Internet is functioning normally, just to shove in > front of the line? ...which leads to two other things to keep in mind. GETS is a pay-for-use service in the US. the carriers are not mandated to offer the service, nor are they providing it for free. the US government pays for it, just like any other client. IF we end up with some measure of support in portions of the Internet, the same pay-for-use service will ideally be in place. my personal opinion is that I rather like this business approach to things and would dread regulation to replace it. the other things to keep in mind is that access to GETS roams with the individual. so if an official is at home (or at a sporting event) and hears that an earthquake occured, he/she is not going to have information about whether phone service is having a problem in order to decide whether a GETS call needs to be made. regards, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 07:00:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02662 for ; Sun, 19 May 2002 07:00: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 GAA00360; Sun, 19 May 2002 06:55: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 GAA00327 for ; Sun, 19 May 2002 06:55:17 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02507 for ; Sun, 19 May 2002 06:55:01 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 179OLK-0001aZ-00; Sun, 19 May 2002 06:55:14 -0400 Date: Sun, 19 May 2002 06:55:14 -0400 (EDT) From: Sean Donelan To: Ken Carlberg cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-Reply-To: <10309.1021798207@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Sun, 19 May 2002, Ken Carlberg wrote: > ...which leads to two other things to keep in mind. GETS is a > pay-for-use service in the US. the carriers are not mandated to offer > the service, nor are they providing it for free. the US government pays > for it, just like any other client. IF we end up with some measure of > support in portions of the Internet, the same pay-for-use service will > ideally be in place. my personal opinion is that I rather like this > business approach to things and would dread regulation to replace it. The telephone system individually priced each calling card call long before GETS was created. A direct-dial call is priced differently than an operator assisted call, or credit card call. The GETS card fits the telephone billing process, and each call is billed at the appropriate rate. The Internet doesn't have a billing or accounting system to charge the government different rates for individual mail messages, or telnet sessions with different types of handling. Or are you proposing a differentiated billing and accounting mechanism for the Internet to enable the government to buy different a priority for each packet? I like the business-like approach too. But I'm not sure if we should be turning the Internet upside down and inside out just so the government can pay 15 cents to make a calls across the Internet. Re-engineering the Internet before we're certain what the problem with using the Internet as it currently exists doesn't make business sense to me. In the last year there has been more evidence of calls attempted with GETS failing to complete through the telephone network than evidence of calls using the Internet failing during an emergency. If 97% completion rate of calls through GETS is satisfactory, and the Internet achieves completion rates above 97%, what is the problem we are trying to solve? Problem statement: The Internet must complete 97% of emergency communications. Solutions: 1. More capacity 2. End-to-end QoS of streams across providers 3. Individual marking of packets with on-demand authentication using a telephone calling card number, and billing for those packets > the other things to keep in mind is that access to GETS roams with the > individual. so if an official is at home (or at a sporting event) and > hears that an earthquake occured, he/she is not going to have > information about whether phone service is having a problem in order to > decide whether a GETS call needs to be made. The telephone network has a nifty feature which immediately informs an user when his or her call can not be completed through the normal circuits called an "all circuits are busy" signal (or special information tone and message, or whatever). An official can immediately learn that the telephone network is having problems simply by making a normal call to check on whatever he or she needs to check. If the telephone network is operating normally, his or her call will go through normally. When the call gets a "Your call can not be completed due to an earthquake in the area," the official immediately knows he or she needs to pay extra to use a GETS card to make the call. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 08:49:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05679 for ; Sun, 19 May 2002 08:49:56 -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 IAA05536; Sun, 19 May 2002 08:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05501 for ; Sun, 19 May 2002 08:43:35 -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 IAA05493 for ; Sun, 19 May 2002 08:43:15 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 19 May 2002 13:43:28 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Sean Donelan cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-reply-to: Your message of "Sun, 19 May 2002 06:55:14 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 May 2002 13:43:27 +0100 Message-ID: <18387.1021812207@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 > The telephone system individually priced each calling card call long > before GETS was created. A direct-dial call is priced differently than > an operator assisted call, or credit card call. The GETS card fits > the telephone billing process, and each call is billed at the appropriate > rate. um, right. > The Internet doesn't have a billing or accounting system to charge > the government different rates for individual mail messages, or telnet > sessions with different types of handling. Or are you proposing a > differentiated billing and accounting mechanism for the Internet to > enable the government to buy different a priority for each packet? how are you getting from the first part of your comment to this? the part of my earlier message that you did not include was... "... IF we end up with some measure of support in portions of the Internet, the same pay-for-use service will ideally be in place. ..." ...the words "IF" "some" and "portions" are very important. if someone is going to contract a service better than best effort, their going to have to pay for it. if the service can't be provided, its going to be best effort, and they'll have to live with it. life goes on. > I like the business-like approach too. But I'm not sure if we should > be turning the Internet upside down and inside out just so the government > can pay 15 cents to make a calls across the Internet. Re-engineering > the Internet before we're certain what the problem with using the > Internet as it currently exists doesn't make business sense to me. um, ok > In the last year there has been more evidence of calls attempted with > GETS failing to complete through the telephone network than evidence > of calls using the Internet failing during an emergency. fantastic!! please provide the raw data for this (specifically, for IP telephony) to make sure we're not comparing apples and oranges. the information you provide will also save the government some money by removing those telco folks from the RBOCs and IXCs that are on GETS authorized list and have used it over the past year. no need for the US government to pay for folks at places like Southwestern Bell to use GETS if they can do it better with their own own IP telephony system. > If 97% > completion rate of calls through GETS is satisfactory, and the > Internet achieves completion rates above 97%, what is the problem we > are trying to solve? you're joking. we'll assume you're speaking about best effort VoIP when you talk of "Internet..completion rates".....and you want to do a straight comparison between best effort VoIP with toll quality telephony? you'll get what you'll pay for. > Problem statement: > > The Internet must complete 97% of emergency communications. > > Solutions: > > 1. More capacity > 2. End-to-end QoS of streams across providers > 3. Individual marking of packets with on-demand authentication > using a telephone calling card number, and billing for those > packets since these are your solutions (and assuming you're aiming for number 1), how does this allow me to bridge IP telephony via SIP/H.323 with the NS/EP marking of IAM messages of the SS7 world? > The telephone network has a nifty feature which immediately informs > an user when his or her call can not be completed through the normal > circuits called an "all circuits are busy" signal (or special information > tone and message, or whatever). An official can immediately learn that > the telephone network is having problems simply by making a normal call > to check on whatever he or she needs to check. If the telephone network > is operating normally, his or her call will go through normally. When > the call gets a "Your call can not be completed due to an earthquake in > the area," the official immediately knows he or she needs to pay extra to > use a GETS card to make the call. cool. have a nice day, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 11:02: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 LAA10057 for ; Sun, 19 May 2002 11:02: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 KAA11885; Sun, 19 May 2002 10:57: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 KAA11853 for ; Sun, 19 May 2002 10:57:23 -0400 (EDT) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09815 for ; Sun, 19 May 2002 10:57:07 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v32.5.) id l.128.11a6688f (4266) for ; Sun, 19 May 2002 10:56:48 -0400 (EDT) Message-ID: <128.11a6688f.2a19172f@aol.com> Date: Sun, 19 May 2002 10:56:47 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_128.11a6688f.2a19172f_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] May 20 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 --part1_128.11a6688f.2a19172f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, A copy of the presentation I plan to use can be found at: http://www-comm.itsi.disa.mil/ieprep While the presentation is on DOD requirements, the above contains some additional related supportive material. Mike Pierce --part1_128.11a6688f.2a19172f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

A copy of the presentation I plan to use can be found at:

http://www-comm.itsi.disa.mil/ieprep

While the presentation is on DOD requirements, the above contains some additional related supportive material.

Mike Pierce
--part1_128.11a6688f.2a19172f_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 16:33: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 QAA20125 for ; Sun, 19 May 2002 16:33: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 QAA00815; Sun, 19 May 2002 16:33: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 QAA00782 for ; Sun, 19 May 2002 16:33:12 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20111 for ; Sun, 19 May 2002 16:32:54 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 179XMc-0001fw-00; Sun, 19 May 2002 16:33:10 -0400 Date: Sun, 19 May 2002 16:33:10 -0400 (EDT) From: Sean Donelan To: Ken Carlberg cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-Reply-To: <18387.1021812207@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Sun, 19 May 2002, Ken Carlberg wrote: > "... IF we end up with some measure of support in portions of the > Internet, the same pay-for-use service will ideally be in place. ..." > > ...the words "IF" "some" and "portions" are very important. Those are pretty big If's. Changing an economic system of an industry in order to implement a protocol is an amazing challenge for engineers. Are there any solutions for enabling emergency communications across the Internet which don't require altering the business model of the existing Internet? > fantastic!! please provide the raw data for this (specifically, for > IP telephony) to make sure we're not comparing apples and oranges. > the information you provide will also save the government some money by > removing those telco folks from the RBOCs and IXCs that are on GETS > authorized list and have used it over the past year. no need for the > US government to pay for folks at places like Southwestern Bell to use > GETS if they can do it better with their own own IP telephony system. Well, I'm more interested in getting the communications through in an emergency rather than who gets paid to carry it. If Avian Carrier Pidgens Communications, Inc. has working communication channels in an emergency, they should be used. Despite having no support for GETS, Blackberry pagers have become very popular with emergency officials. If you believe the statistics, UUNET claims they have been delivering on average over 99% of all packets on their backbone for over a year. http://www1.worldcom.com/us/about/network/latency/ AT&T, C&W and Sprint make similar reliablity claims for their IP backbones. Comparing apples and apples is interesting if everyone sold the same apples. Try an orange, you might like it. Attempting to make an orange look like an apple destroys a perfectly good orange, and doesn't make a very good apple. I am working with people who are deploying an IP telephony system for use in an emergency. The goals include evaluating how well it performs during periods of network stress, and what problems it has. Only after we figure out what the problems are, will we be in a postion to identify solutions to those problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 17:23: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 RAA21706 for ; Sun, 19 May 2002 17:23: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 RAA03769; Sun, 19 May 2002 17:23: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 RAA03737 for ; Sun, 19 May 2002 17:23:31 -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 RAA21686 for ; Sun, 19 May 2002 17:23:14 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 19 May 2002 22:23:24 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Sean Donelan cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-reply-to: Your message of "Sun, 19 May 2002 16:33:10 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 May 2002 22:23:23 +0100 Message-ID: <7823.1021843403@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 > Those are pretty big If's. Changing an economic system of an industry > in order to implement a protocol is an amazing challenge for engineers. > > Are there any solutions for enabling emergency communications across the > Internet which don't require altering the business model of the existing > Internet? I'm sorry, but what are you talking about? what is the economic system that you are refering too, and what is the change to that you feel I'm advocating? > If you believe the statistics, UUNET claims they have been delivering > on average over 99% of all packets on their backbone for over a year. > > http://www1.worldcom.com/us/about/network/latency/ > > AT&T, C&W and Sprint make similar reliablity claims for their IP > backbones. excuse me, but you've made the following claim.... > In the last year there has been more evidence of calls attempted with > GETS failing to complete through the telephone network than evidence > of calls using the Internet failing during an emergency. ...based on the *internal* stats of four *tier-1* carriers? and what does that number tell us about IP telephony traffic that they carry? ---------- actually, in giving it some thought, I made an error in judgement in my last email. you stated previously: > I like the business-like approach too. But I'm not sure if we should > be turning the Internet upside down and inside out just so the government > can pay 15 cents to make a calls across the Internet. Re-engineering > the Internet before we're certain what the problem with using the > Internet as it currently exists doesn't make business sense to me. I should have first asked, who is suggesting that the internet be re-engineered? and more importantly, which document states this, and where exactly does it say this? > I am working with people who are deploying an IP telephony system for > use in an emergency. The goals include evaluating how well it performs > during periods of network stress, and what problems it has. Only after > we figure out what the problems are, will we be in a postion to identify > solutions to those problems. my best wishes in your endeavors, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun May 19 18:38: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 SAA25099 for ; Sun, 19 May 2002 18:38: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 SAA08704; Sun, 19 May 2002 18:38: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 SAA08674 for ; Sun, 19 May 2002 18:38:47 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25071 for ; Sun, 19 May 2002 18:38:30 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 179ZK4-0001hd-00; Sun, 19 May 2002 18:38:40 -0400 Date: Sun, 19 May 2002 18:38:40 -0400 (EDT) From: Sean Donelan To: Ken Carlberg cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-Reply-To: <7823.1021843403@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Sun, 19 May 2002, Ken Carlberg wrote: > I should have first asked, who is suggesting that the internet be > re-engineered? and more importantly, which document states this, > and where exactly does it say this? "ETS is a pay-for-use service in the US. the carriers are not mandated to offer the service, nor are they providing it for free. the US government pays for it, just like any other client. IF we end up with some measure of support in portions of the Internet, the same pay-for-use service will ideally be in place." If ETS is a pay-for-use service, someone will need to re-engineer the Internet to include the infrastructure to support pay-for-use billing. Many people have been working on that for a long time, but it doesn't seem to be here yet. What if the ideal billing infrastructure isn't in place, how will ETS be supported? $19.95 a month for all the priority packets you can send? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 20 04:29: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 EAA00006 for ; Mon, 20 May 2002 04:29: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 EAA17051; Mon, 20 May 2002 04:28: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 EAA17024 for ; Mon, 20 May 2002 04:28:25 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29966 for ; Mon, 20 May 2002 04:28:05 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 20 May 2002 09:28:19 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Sean Donelan cc: ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California In-reply-to: Your message of "Sun, 19 May 2002 18:38:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 May 2002 09:28:16 +0100 Message-ID: <596.1021883296@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 > > I should have first asked, who is suggesting that the internet be > > re-engineered? and more importantly, which document states this, > > and where exactly does it say this? > > "ETS is a pay-for-use service in the US. the carriers are not mandated > to offer the service, nor are they providing it for free. the US > government pays for it, just like any other client. IF we end up with > some measure of support in portions of the Internet, the same > pay-for-use service will ideally be in place." just to clarify, i stated "GETS", not "ETS". > If ETS is a pay-for-use service, someone will need to re-engineer > the Internet to include the infrastructure to support pay-for-use > billing. Many people have been working on that for a long time, > but it doesn't seem to be here yet. where is here? I'm really weak regarding billing, but I'll bring up some information that I know off the top of my head. 1) AT&T is offering diff-serv marked service. I have not obtained details because then I'm stuck with an NDA, but I'll bet a couple of pints that this service is an an additional cost beyond best effort service to use it. 2) in the states, we've had fractional T-1 service for a while where a flat fee is charged for some threshold, and an additional charge is made when you exceed the threshold -- an additional pay-as-you-use service. 3) In New Zealand, large customers (eg, schools) are charged on a per-IP packet basis for traffic they obtain from outside of the country. The same used to be true for Chile (my info on it is 3 years old). All in-country traffic in Chile was charged at a flat rate, but in-bound traffic from outside the country was charged as you obtained it. My assumption is that this model applies to other countries where international tariffs are still relatively high. > What if the ideal billing > infrastructure isn't in place, how will ETS be supported? $19.95 > a month for all the priority packets you can send? what is considered "ideal" is rather relative. economic theory by Keyes or Adams would probably state that the billing needs to recover costs as well as be acceptable to the target audience. the thread seems to be drifting away to economics. if you wish to continue with that, lets take this off line. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 20 06:04: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 GAA03320 for ; Mon, 20 May 2002 06:04:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21815; Mon, 20 May 2002 06:03: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 GAA21773 for ; Mon, 20 May 2002 06:03:36 -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 GAA03277 for ; Mon, 20 May 2002 06:03:18 -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 DAA16914 for ; Mon, 20 May 2002 03:03:33 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with SMTP id AAA657F for ; Mon, 20 May 2002 03:03:32 -0700 Received: FROM agcs.com BY mkultra ; Mon May 20 03:03:36 2002 -0700 Message-ID: <3CE8C9F9.8D266989@agcs.com> Date: Mon, 20 May 2002 03:03:37 -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: Sean Donelan , ieprep@ietf.org Subject: Re: No GETS activityRE:[Ieprep] Fwd: Re: 5.2 Earthquake in Northern California References: <10309.1021798207@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Ken, The other thing that should be pointed out is that while an authorized emergency user may place a GETS call anytime, that call does not "just to shove in front of the line". (One would of course first need a line in order to be able to shove to its front.) If, as it has been suggested, there was no network congestion in this case, then the GETS call completed normally, as did all of the POTS calls. There is some misconception that GETS calls somehow get accepted first, faster, etc. in the PSTN. GETS calls can better be viewed as less subject to failure by blockage when there is congestion, but otherwise look remarkably like a credit card call. Ken Carlberg wrote: > > > attached here is the 115 isolated by clli and 30 minute interval of the > > > near 200 or so calls of which only 7 came into the state" > > > > I'm confused. Was the public telephone network congested to require > > the use of GETS at all on Tuesday? Were normal calls being blocked on > > Tuesday, which required designated users to invoke GETS special handling? > > The only FCC outage report on Tuesday was in Norfolk Virginia, all > > inter-office, long distance and 9-1-1 service was out for 50,000+ people > > due to yet another DACS failure. > > > > Shouldn't the number of GETS calls be zero, except during a massive > > telephone problem? > > so, lets see, if we look at the numbers there is (roughly) 50K+ > authorized users of GETS....and yet 200 calls were made. not bad when > you consider that some percentage are testing for service (could be > govenrmnet OR carrier technicians) and/or checking for fraud -- which > i'm sure you're aware is common place action to take. and then the rest > are probably officials making an emergency call. actually, quite a > restrained number in my opinion.... > > > If a GETS-like service is introduced into the Internet, is this just > > during "emergencies" or is the government expecting to use GETS all the > > time, even when the Internet is functioning normally, just to shove in > > front of the line? > > ...which leads to two other things to keep in mind. GETS is a > pay-for-use service in the US. the carriers are not mandated to offer > the service, nor are they providing it for free. the US government pays > for it, just like any other client. IF we end up with some measure of > support in portions of the Internet, the same pay-for-use service will > ideally be in place. my personal opinion is that I rather like this > business approach to things and would dread regulation to replace it. > > the other things to keep in mind is that access to GETS roams with the > individual. so if an official is at home (or at a sporting event) and > hears that an earthquake occured, he/she is not going to have > information about whether phone service is having a problem in order to > decide whether a GETS call needs to be made. > > regards, > > -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 Mon May 20 12:17: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 MAA12524 for ; Mon, 20 May 2002 12:17: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 MAA17315; Mon, 20 May 2002 12:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17286 for ; Mon, 20 May 2002 12:16:40 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12228 for ; Mon, 20 May 2002 12:16:23 -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 g4KGGHT12610; Mon, 20 May 2002 17:16:19 +0100 From: "Alistair Munro" To: "'Folts, Harold'" , "'ieprep List \(E-mail\)'" Date: Mon, 20 May 2002 17:18:14 +0100 Message-ID: <005401c20019$f32277e0$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Ieprep] IEPREP interim meeting - thanks for setting up the teleconference bridge Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Hal, Thanks for setting this up. It has been very interesting to listen (in silence so far) to the discussions, even though the acoustics are obviously not ideal. I'll log in again from home later if I get a chance. Best 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 > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of Folts, Harold > Sent: 06 May 2002 19:54 > To: ieprep List (E-mail) > Subject: [Ieprep] RE: ieprep telecom > > > I have made arrangements for a conference bridge through NASA. > > It is for 20 May from 9:00 am to 2:00 pm > > It is toll-free dial-in @ 888 820-8951 Pass Code 25508 Conf > leader: Hal Folts You will need to provide the pass code and > my name when asked. > > I have 10 ports including the one for the meeting. I can add > more if there is an indication of more than 9 dialing in. > > Hal > > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com] > > Sent: Thursday, May 02, 2002 2:24 AM > > To: Folts, Harold > > Subject: Re: ieprep telecom > > > > > > At 01:01 PM 5/1/2002 -0400, Folts, Harold wrote: > > >How many would you expect to tune into a teleconference > > bridge for the > > >meeting? > > > > so far I have seven who have said they would like to have the > > facility. My > > inclination is to overshoot a little and allow for ten. If I > > get a larger > > number than that, I'll let you know. > > > > _______________________________________________ > 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 May 20 17:31: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 RAA13288 for ; Mon, 20 May 2002 17:31: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 RAA15013; Mon, 20 May 2002 17:26: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 RAA14979 for ; Mon, 20 May 2002 17:26:45 -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 RAA12831 for ; Mon, 20 May 2002 17:26:25 -0400 (EDT) Received: from FRED-W2K6.cisco.com (va-dhcp89-48.cisco.com [161.44.89.48]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4KLQDPJ024194; Mon, 20 May 2002 14:26:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20020520124450.01b13638@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 May 2002 12:46:05 -0400 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Interim Meeting Attendees 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 If you were on the telephone today for the ieprep interim meeting, please drop me a note privately, so I can update the "blue" sheet. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 20 18:00: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 SAA15394 for ; Mon, 20 May 2002 18:00: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 SAA17911; Mon, 20 May 2002 18:00: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 SAA17877 for ; Mon, 20 May 2002 18:00:10 -0400 (EDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15340 for ; Mon, 20 May 2002 17:59:49 -0400 (EDT) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA28829 for ; Mon, 20 May 2002 15:01:51 -0700 Message-Id: <5.1.1.2.2.20020520144804.033593b0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 20 May 2002 14:59:56 -0700 To: ieprep@ietf.org From: Dave Crocker In-Reply-To: References: <7823.1021843403@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Internet QOS Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 06:38 PM 5/19/2002 -0400, Sean Donelan wrote: >If ETS is a pay-for-use service, someone will need to re-engineer >the Internet to include the infrastructure to support pay-for-use >billing. The larger issue is that the current Internet is a single service (best effort) environment. If the Internet is going to support end-to-end Quality of Service, there are likely to be changes to the general Internet accounting system to handle the different services. My own view is that end-to-end QOS is, in fact, required. I've no sympathy for the design model that says just use bigger pipes. It ignores details in the history and nature of packet-switching research: Queuing is for transients, not for handling high averages. High averages require denial at the leaves and/or bigger pipes. It is not possible to guarantee that pipes are always "too" large, so congestion is guarantee to occur at some point, even for the simplistic model, ignoring the likelihood that it is not economically feasible. Denial for high averages and for both methods of handling high transients -- dropping packets or queuing -- all require prioritization. Prioritization rules define QOSs... Stated less predictively: Whatever accounting model is used to support other kinds of quality of service seems likely to be able to satisfy IEPS accounting requirements. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 20 19:54: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 TAA22461 for ; Mon, 20 May 2002 19:54: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 TAA26828; Mon, 20 May 2002 19:53: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 TAA26794 for ; Mon, 20 May 2002 19:53:45 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22385 for ; Mon, 20 May 2002 19:53:27 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 179wyB-0002U2-00 for ieprep@ietf.org; Mon, 20 May 2002 19:53:39 -0400 Date: Mon, 20 May 2002 19:53:39 -0400 (EDT) From: Sean Donelan To: ieprep@ietf.org Subject: Re: [Ieprep] Internet QOS In-Reply-To: <5.1.1.2.2.20020520144804.033593b0@jay.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Mon, 20 May 2002, Dave Crocker wrote: > Stated less predictively: Whatever accounting model is used to support > other kinds of quality of service seems likely to be able to satisfy IEPS > accounting requirements. That's great. We've been waiting for 10 years for a new QoS model to take hold. When the new accounting model is ready we'll use it. In the mean time, can we do something for emergency services before this new accounting model is deployed on the Internet? To be more practical, can we deploy "simple" emergency service within a few years using what is available today (or with the fewest changes) or must we wait for the Internet to catch up with IEPS requirements. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon May 20 21:18: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 VAA26860 for ; Mon, 20 May 2002 21:18: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 VAA02442; Mon, 20 May 2002 21:18: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 VAA02410 for ; Mon, 20 May 2002 21:18:29 -0400 (EDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26817 for ; Mon, 20 May 2002 21:18:10 -0400 (EDT) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA32642; Mon, 20 May 2002 18:20:04 -0700 Message-Id: <5.1.1.2.2.20020520180444.0325deb8@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 20 May 2002 18:13:58 -0700 To: Sean Donelan From: Dave Crocker Subject: Re: [Ieprep] Internet QOS Cc: ieprep@ietf.org In-Reply-To: References: <5.1.1.2.2.20020520144804.033593b0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 07:53 PM 5/20/2002 -0400, Sean Donelan wrote: >On Mon, 20 May 2002, Dave Crocker wrote: > > Stated less predictively: Whatever accounting model is used to support > > other kinds of quality of service seems likely to be able to satisfy IEPS > > accounting requirements. > >That's great. We've been waiting for 10 years for a new QoS model to >take hold. alas, I remember initial arpanet/internet efforts at this somewhere around 25 years ago. but that's just quibbling, of course, except for one very important implication, namely how slowly things change. >When the new accounting model is ready we'll use it. I was not suggesting waiting on anything. Rather I was noting that inter-provider changes are required and that changes to accounting go hand-in-hand with changes to service. Oh. And I was suggesting that IEPS should piggyback on those activities, rather than postulating any infrastructure changes that are unique to IEPS. A different point than the one I was making -- and probably the one that you are very properly focusing on -- is that in the near term, we have what we have, both for infrastructure service and infrastructure accounting. They ain't gonna change anytime soon. >In the mean time, can we do something for emergency services before >this new accounting model is deployed on the Internet? To be more >practical, can we deploy "simple" emergency service within a >few years using what is available today (or with the fewest changes) >or must we wait for the Internet to catch up with IEPS requirements. 1. We can deploy edge services easily in the end-point hosts. Probably not all that useful. 2. We can deploy edge ISP services with more difficulty, but more utility. In effect this would be a client/server service model, concerning access. The attaching host uses standardized ways of requesting special services from the ISP they are attaching to. What happens within the cloud is a separate matter. It occurs to me that one can easily imagine "regional" agreements among ISPs happening more quickly than international one. However, the dominance of a few major US-based ISPs makes this possibility weaker. In any event, it explicitly defers the end-to-end details, while providing a mechanism for users to request special service. That would probably be generally helpful for the Internet. 3. ...can't think of an alternative... d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 21 04:19: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 EAA27204 for ; Tue, 21 May 2002 04:19: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 EAA01582; Tue, 21 May 2002 04:18: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 EAA01546 for ; Tue, 21 May 2002 04:18:43 -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 EAA27149 for ; Tue, 21 May 2002 04:18:24 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 21 May 2002 09:18:36 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Dave Crocker cc: Sean Donelan , ieprep@ietf.org Subject: Re: [Ieprep] Internet QOS In-reply-to: Your message of "Mon, 20 May 2002 18:13:58 PDT." <5.1.1.2.2.20020520180444.0325deb8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 May 2002 09:18:35 +0100 Message-ID: <546.1021969115@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 ... > 3. ...can't think of an alternative... one can deploy VoIP within certain environments as it exists today. Vendor-proprietary solutions to compensate for loss in times of congestion can be used between clients using the same products or tools. Redundant transmissions or FEC can also be used along the same line of reasoning. IM type applications and email can be used to supplement voice. however, the point about the above is that one doesn't need a working group to do that or point out the obvious. It already exists. I'm not concerned about best effort VoIP. when someone suggests using it, great. its a non-issue. I am concerned about when you want to go beyond that, and just as importantly, when providers are offering service beyond that. there is nothing in the IEPREP charter that says what it produces is the only way to do something regarding emergency communications. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 21 07:47: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 HAA05471 for ; Tue, 21 May 2002 07:47: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 HAA12730; Tue, 21 May 2002 07:47:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12696 for ; Tue, 21 May 2002 07:47:04 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05466 for ; Tue, 21 May 2002 07:46:40 -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 g4LBkmT28735; Tue, 21 May 2002 12:46:51 +0100 From: "Alistair Munro" To: "'Ken Carlberg'" , "'Dave Crocker'" Cc: "'Sean Donelan'" , Subject: RE: [Ieprep] Internet QOS Date: Tue, 21 May 2002 12:48:47 +0100 Message-ID: <000f01c200bd$7adfa010$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <546.1021969115@cs.ucl.ac.uk> 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 Hi All, At the risk of reopening an earlier discussion that ran ahead of requirements, I agree that we should make statements about best practice on QoS. So far, there has not been any advance on Fred's text in his requirements draft and we should look again at this issue in due course. There *is* a discernable end-to-end QoS model for IP already, arguably three if you consider MPLS as part of IP, and I believe it/they, together with proper network planning would work well in many emergency situations. In fact, they will work better than any other QoS/GoS model because they will survive congestion better *because of* the statistical multiplexing effects. Specifications for using what exists already to best effect are what we should bring out in best practice statements and I would resist any claim that an[other?] end-to-end QoS model is needed. What exactly did you have in mind? I don't know much about accounting/pricing/charging models and I don't see how they fit in to a discussion on QoS, (or indeed into IEPREP). Pricing is a tool for limiting use but it is not a quality model. Could you explain the relationship please? 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 > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of Ken Carlberg > Sent: 21 May 2002 09:19 > To: Dave Crocker > Cc: Sean Donelan; ieprep@ietf.org > Subject: Re: [Ieprep] Internet QOS > > > > ... > > > 3. ...can't think of an alternative... > > one can deploy VoIP within certain environments as it exists today. > Vendor-proprietary solutions to compensate for loss in times of > congestion can be used between clients using the same products or > tools. Redundant transmissions or FEC can also be used along > the same > line of reasoning. > > IM type applications and email can be used to supplement voice. > > however, the point about the above is that one doesn't need a working > group to do that or point out the obvious. It already exists. > > I'm not concerned about best effort VoIP. when someone > suggests using it, great. its a non-issue. I am concerned > about when you want to go > beyond that, and just as importantly, when providers are offering > service beyond that. > > there is nothing in the IEPREP charter that says what it produces is > the only way to do something regarding emergency communications. > > -ken > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 21 10:14: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 KAA11320 for ; Tue, 21 May 2002 10:14: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 KAA20239; Tue, 21 May 2002 10:12: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 KAA20206 for ; Tue, 21 May 2002 10:12:40 -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 KAA11247 for ; Tue, 21 May 2002 10:12:21 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 56B8567103; Tue, 21 May 2002 10:43:51 -0400 (EDT) Date: Tue, 21 May 2002 10:12:05 -0400 Subject: Re: [Ieprep] Internet QOS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: To: "Alistair Munro" From: RJ Atkinson In-Reply-To: <000f01c200bd$7adfa010$31281eac@degree2.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 21, 2002, at 07:48 , Alistair Munro wrote: > Hi All, > > At the risk of reopening an earlier discussion that ran ahead of > requirements, I agree that we should make statements about best practice > on QoS. So far, there has not been any advance on Fred's text in his > requirements draft and we should look again at this issue in due course. That proposal seems (to me) to be inconsistent with the WG charter for IEprep. The chair, of course, is the only person who can officially interpret the charter. However, I'll point out that A LOT of what is being discussed here is much more properly handled as a private business arrangement, between DISA/NCS and whichever telecom/ISP firms it contracts with, than as an IETF standards activity. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 21 19:58: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 TAA06416 for ; Tue, 21 May 2002 19:58: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 TAA22321; Tue, 21 May 2002 19:58: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 TAA22291 for ; Tue, 21 May 2002 19:58:28 -0400 (EDT) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06403 for ; Tue, 21 May 2002 19:58:11 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v32.5.) id l.71.1fbdea5c (4266) for ; Tue, 21 May 2002 19:57:56 -0400 (EDT) Message-ID: <71.1fbdea5c.2a1c3904@aol.com> Date: Tue, 21 May 2002 19:57:56 EDT To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_71.1fbdea5c.2a1c3904_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] Resource priority header 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_71.1fbdea5c.2a1c3904_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, Following the discussion in the interim meeting, I would offer the following ideas for the Resource-priority header: As Fred suggested, the values for some namespace may be used for something that is not actually an ordered set of priorities, but I would propose leaving the header named "Resource-priority" since that is the intended use. The actual contents could be left as "namespace.priority" or changed to "namespace.value" to indicate this more general use. 3. After the third paragraph, the following should be added before the table entry: The following is an extension of Table 3 in [2543bis] for the new header field defined here: Header field where proxy ACK BYE CAN INV OPT REG ________________________________________________________________ Resource-Priority c ar - - - O - - 4. If allowed to be something other than an ordered list, then the IANA Considerations would need to to reworded a bit to say "Within each namespace, the registration MUST indicate if the values represent an ordered set and, if so, the relative precedence levels expressed as an ordered list." Further, I would presume that, if an unordered set were created for some namespace, that there would be no restrictions to adding values. 5. Security Considerations While it is true that use of this header can give someone more or better access and allow them to consume resources easier or faster, I think the point should still be made that the Resource-priority header does not introduce any unique requirement for security procedures. The procedures required are the same as those required to authenticate/authorize the use of many other headers and capabilities. The question of default values (when the header is not present or the namespace or value is unknown) is a problem. For dsn, the practice might be to default to the lowest if the header is not present. I suppose if the value is unknown, it should default to the lowest also, but I think it really represents a bigger problem (data corruption?) and the practice may be to reject the session setup. Unknown namespace is another issue. If a device is supposed to handle multiple namespaces, then it can not default to one of them if it doesn't understand the received namespace. Further, in a network (like dsn) which is set up to handle exactly one namespace, getting one that is does not understand indicates a bigger problem (a call crossed some boundary it shouldn't have). The policy would more likely be to reject the call. I would suggest not saying much about defaults, especially since it really doesn't affect the definition of the header itself. If something must be said, I suggest text in Annex A similar to the following: When the Resource-priority header is missing or is present but contains an unknown priority value and the receiver is only expected to support a single namespace, any procedures applied SHOULD be the same as would be applied when the lowest defined value (Routine) is specified. When the Resource-priority header is missing and the receiver is expected to support more than one namespace, it MUST NOT apply any procedures related to priority and SHOULD pass the request on with the same Resource-priority header (or lack thereof). When the Resource-priority header contains an unknown namespace and the receiver is expected to support more than one namespace, it SHOULD reject the request in which the Resource-priority header was included. (I know the last sentence causes some people trouble, since it is saying to reject a session setup based on the contents of an optional header. Is this a no-no?) Don't forget to add "critic-ecp" to the text in the first paragraph of Annex A. With the addition of a new namespace for IPREP, it seems that the reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS call can't take precedence over a "Flash-Override call in the dsn. I suggest replacing the final paragraph of Annex A with something like the following: The value "critic-ecp" stands for "Critical and Emergency Call Processing" and is generally used only to support those activities related to restoration of communications. Its use is extremely limited and is not specified here. For the namespace q735, the defaults are another issue. The intention was to supported interworking with PSTN in which a SIP portion provides the link between 2 PSTN parts. This header then just provides the place to put the equivalent information from the ISUP messages. In this case, there would not be a default. It simply carries what it gets. At the end, when mapping back to ISUP, undefined values can not be mapped so may be defaulted to the lowest, but I don't see that this needs to be specified here. Perhaps a paragraph added to say something like: Since the intention of this namespace is to provide interworking between Q.735.3 entities without interpretation by the SIP proxies, no default in the case of no header or a header with an unknown priority value is required. Each MUST carry the header (or lack thereof) exactly as received. The mapping back to Q.735.3 requires that the namespace be correct and that unknown priority values be discarded or changed to the lowest defined. (Remember to change the definition so that "0" is the highest and "4" is the lowest.) For IEPREP, the job is to add the definition of the namespace. I believe that, while the namespace would be added to support the specific requirements of IEPREP, it is something that exists in a broader context - the public network. Within that network, the new value(s) for IEPREP are in addition to the case of "normal" calls, even if the normal calls never use the Resource-priority header. It seems necessary to actually define a "Normal" priority value, simply to be able to say that something defaults to it. Also, the idea has been raised before about the desire to have several values of priority for authorized emergency. (I mean ascending levels of priority, not labels that have no specific meaning.) Also, while 911 emergency type calls may be indicated by another means ("SOS"), it seems that there still is a need to include a priority level in this set for it. Otherwise, it is not straightforward to specify relative priority handling. Therefore, I would propose to add an Annex C as follows (where the actual name of the namespace is open for discussion): ------------------------------------------------------------------------------ ---------------------------------------------- C Namespace public_network The namespace "public_network" is registered here to be used by those public networks which support the emergency services defined in [IEPS/SOS/911/etc]. The namespace contains the following five priority values in ascending order: Normal (Although all normal calls are expected to not contain this header, the value is defined for completeness and to allow the specification of the default.) Emergency_public (Although public emergency calls may be indicated by other means, e.g., "SOS", this value is defined for completeness and to allow sufficient definition of its relationship to the higher priority levels.) Emergency_auth_1 (The assignment and use of this priority level is the responsibility of the network operator/telecommunications agency in the country, etc. Emergency_auth_2 " Emergency_auth_3 " Within a network which is expected to support only this one namespace, when the Resource-priority header is missing or is present but contains an unknown priority value, any procedures applied SHOULD be the same as if the lowest value (Normal) had been specified. When the Resource-priority header contains an unknown namespace, the receiver SHOULD reject the request in which the Resource-priority header was included. -----------------------------(End of proposed Annex C) ------------------------------------------------ An alternative to the above Annex is to recognize that the definition of this is unique to each country and let each one register with IANA for their namespace, including procedures. This would allow a choice of the number of levels. There was some discussion of interworking with GSM which, according to various descriptions has 7 or 15 priority levels. I understand from recent e-mails, that it has 7, as I included in my presentation. The 15 levels also referred to are not priority levels as Janet Gunn explained., but rather access classes which can be turned on or off by the service provider to allow certain groups of handsets to get service. As such, they are not "priority levels" and they do not need to be passed anywhere for interworking. The Resource-priority header would only need to deal with the actual 7 priority levels. Do we know what they are called and what interworking might be required? Mike Pierce --part1_71.1fbdea5c.2a1c3904_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all,

Following the discussion in the interim meeting, I would offer the following ideas for the Resource-priority header:

As Fred suggested, the values for some namespace may be used for something that is not actually an ordered set of priorities, but I would propose leaving the header named "Resource-priority" since that is the intended use. The actual contents could be left as "namespace.priority" or changed to  "namespace.value" to indicate this more general use.

3. After the third paragraph, the following should be added before the table entry:

  The following is an extension of Table 3 in [2543bis] for the
  new header field defined here:
  Header field             where     proxy ACK BYE CAN INV OPT REG
  ________________________________________________________________
  Resource-Priority         c          ar   -   -   -   O   -   -


4. If allowed to be something other than an ordered list, then the IANA Considerations would need to to reworded a bit to say "Within each namespace, the registration MUST indicate if the values represent an ordered set and, if so, the relative precedence levels expressed as an ordered list." Further, I would presume that, if an unordered set were created for some namespace, that there would be no restrictions to adding values.

5. Security Considerations

While it is true that use of this header can give someone more or better access and allow them to consume resources easier or faster, I think the point should still be made that the Resource-priority header does not introduce any unique requirement for security procedures. The procedures required are the same as those required to authenticate/authorize the use of many other headers and capabilities.

The question of default values (when the header is not present or the namespace or value is unknown) is a problem.

For dsn, the practice might be to default to the lowest if the header is not present. I suppose if the value is unknown, it should default to the lowest also, but I think it really represents a bigger problem (data corruption?) and the practice may be to reject the session setup. Unknown namespace is another issue. If a device is supposed to handle multiple namespaces, then it can not default to one of them if it doesn't understand the received namespace. Further, in a network (like dsn) which is set up to handle exactly one namespace, getting one that is does not understand indicates a bigger problem (a call crossed some boundary it shouldn't have). The policy would more likely be to reject the call. I would suggest not saying much about defaults, especially since it really doesn't affect the definition of the header itself. If something must be said, I suggest text in Annex A similar to the following:

When the Resource-priority header is missing or is present but contains an unknown priority value and the receiver is only expected to support a single namespace, any procedures applied SHOULD be the same as would be applied when the lowest defined value (Routine) is specified. When the Resource-priority header is missing and the receiver is expected to support more than one namespace, it MUST NOT apply any procedures related to priority and SHOULD pass the request on with the same Resource-priority header (or lack thereof). When the Resource-priority header contains an unknown namespace and the receiver is expected to support more than one namespace, it SHOULD reject the request in which the Resource-priority header was included.

(I know the last sentence causes some people trouble, since it is saying to reject a session setup based on the contents of an optional header. Is this a no-no?)

Don't forget to add "critic-ecp" to the text in the first paragraph of Annex A. With the addition of a new namespace for IPREP, it seems that the reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS call can't take precedence over a "Flash-Override call in the dsn. I suggest replacing the final paragraph of Annex A with something like the following:

The value "critic-ecp" stands for "Critical and Emergency Call Processing" and is generally used only to support those activities related to restoration of communications. Its use is extremely limited and is not specified here.

For the namespace q735, the defaults are another issue. The intention was to supported interworking with PSTN in which a SIP portion provides the link between 2 PSTN parts. This header then just provides the place to put the equivalent information from the ISUP messages. In this case, there would not be a default. It simply carries what it gets. At the end, when mapping back to ISUP, undefined values can not be mapped so may be defaulted to the lowest, but I don't see that this needs to be specified here. Perhaps a paragraph added to say something like:

Since the intention of this namespace is to provide interworking between Q.735.3 entities without interpretation by the SIP proxies, no default in the case of no header or a header with an unknown priority value is required. Each MUST carry the header (or lack thereof) exactly as received. The mapping back to Q.735.3 requires that the namespace be correct and that unknown priority values be discarded or changed to the lowest defined.

(Remember to change the definition so that "0" is the highest and "4" is the lowest.)

For IEPREP, the job is to add the definition of the namespace. I believe that, while the namespace would be added to support the specific requirements of IEPREP, it is something that exists in a broader context - the public network. Within that network, the new value(s) for IEPREP are in addition to the case of "normal" calls, even if the normal calls never use the Resource-priority header. It seems necessary to actually define a "Normal" priority value, simply to be able to say that something defaults to it.

Also, the idea has been raised before about the desire to have several values of priority for authorized emergency. (I mean ascending levels of priority, not labels that have no specific meaning.)

Also, while 911 emergency type calls may be indicated by another means ("SOS"), it seems that there still is a need to include a priority level in this set for it. Otherwise, it is not straightforward to specify relative priority handling.

Therefore, I would propose to add an Annex C as follows (where the actual name of the namespace is open for discussion):

----------------------------------------------------------------------------------------------------------------------------
C Namespace public_network

The namespace "public_network" is registered here to be used by those public networks which support the emergency services defined in [IEPS/SOS/911/etc]. The namespace contains the following five priority values in ascending order:

Normal (Although all normal calls are expected to not contain this header, the value is defined for completeness and to allow the specification of the default.)
Emergency_public (Although public emergency calls may be indicated by other means, e.g., "SOS", this value is defined for completeness and to allow sufficient definition of its relationship to the higher priority levels.)
Emergency_auth_1 (The assignment and use of this priority level is the responsibility of the network operator/telecommunications agency in the country, etc.
Emergency_auth_2 "
Emergency_auth_3 "

Within a network which is expected to support only this one namespace, when the Resource-priority header is missing or is present but contains an unknown priority value, any procedures applied SHOULD be the same as if the lowest value (Normal) had been specified. When the Resource-priority header contains an unknown namespace, the receiver SHOULD reject the request in which the Resource-priority header was included.
-----------------------------(End of proposed Annex C) ------------------------------------------------

An alternative to the above Annex is to recognize that the definition of this is unique to each country and let each one register with IANA for their namespace, including procedures. This would allow a choice of the number of levels.

There was some discussion of interworking with GSM which, according to various descriptions has 7 or 15 priority levels. I understand from recent e-mails, that it has 7, as I included in my presentation. The 15 levels also referred to are not priority levels as Janet Gunn explained., but rather access classes which can be turned on or off by the service provider to allow certain groups of handsets to get service. As such, they are not "priority levels" and they do not need to be passed anywhere for interworking. The Resource-priority header would only need to deal with the actual 7 priority levels. Do we know what they are called and what interworking might be required?

Mike Pierce

--part1_71.1fbdea5c.2a1c3904_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 09:51:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02098 for ; Wed, 22 May 2002 09:51: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 JAA24868; Wed, 22 May 2002 09:49: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 JAA24836 for ; Wed, 22 May 2002 09:49: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 JAA01900 for ; Wed, 22 May 2002 09:48:52 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id ED10467103; Wed, 22 May 2002 10:20:30 -0400 (EDT) Date: Wed, 22 May 2002 09:48:36 -0400 Subject: Re: [Ieprep] Resource priority header Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep@ietf.org To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <71.1fbdea5c.2a1c3904@aol.com> Message-Id: <9D7432A2-6D8A-11D6-8C51-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote: > To all, > > Following the discussion in the interim meeting, I would offer the > following ideas for the Resource-priority header: While protocol design can be amusing to some, I don't think that is within the charter for IEprep. Of course the chair can correct me if he thinks I'm confused... Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 10:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03216 for ; Wed, 22 May 2002 10:07: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 KAA26768; Wed, 22 May 2002 10:06: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 KAA26739 for ; Wed, 22 May 2002 10:06:50 -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 KAA03165 for ; Wed, 22 May 2002 10:06:29 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 May 2002 15:06:27 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 May 2002 15:06:25 +0100 Message-ID: <1168.1022076385@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 > From: Mpierce1@aol.com > > For IEPREP, the job is to add the definition of the namespace. I believe > that, while the namespace would be added to support the specific > requirements of IEPREP, it is something that exists in a broader context > - the public network. Within that network, the new value(s) for IEPREP > are in addition to the case of "normal" calls, even if the normal calls > never use the Resource-priority header. It seems necessary to actually > define a "Normal" priority value, simply to be able to say that something > defaults to it. I'm sorry, but I don't understand what exactly you are saying here. > C Namespace public_network > > The namespace "public_network" is registered here to be used by those > public networks which support the emergency services defined in > [IEPS/SOS/911/etc]. The namespace contains the following five priority > values in ascending order: ugh. I really feel uncomfortable with this. an association of a generic name like "public_network" with a distinct number of priority values really doesn't seem to be desireable. I feel more comfortable starting out with "known" namespaces or levels like MLPP and IEPS/GETS. my udnerstanding is that the ITU will define ETS with 5 levels. and there is e-MLPP with the 15, and GTPS with 3. but some generic and encompassing as "public_network" shouldn't be defined at this time. > From: RJ Atkinson > > While protocol design can be amusing to some, I don't think that is > within the charter for IEprep. Of course the chair can correct me > if he thinks I'm confused... I agree with Ran that the parts of the original message dealing with the protocol specification of the resource-header and the main part of that spec should be moved to SIPPING. the other areas involving IANA and actual namespace values (eg, those discussed above) would seem to be fine for debate here. my 2 pence, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 10:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04509 for ; Wed, 22 May 2002 10:31: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 KAA28437; Wed, 22 May 2002 10:31: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 KAA28401 for ; Wed, 22 May 2002 10:31:28 -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 KAA04506 for ; Wed, 22 May 2002 10:31: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 HAA16576; Wed, 22 May 2002 07:30:55 -0700 (PDT) Message-Id: <4.1.20020522092545.0173a218@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 22 May 2002 09:30:47 -0500 To: RJ Atkinson , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Ieprep] Resource priority header Cc: ieprep@ietf.org In-Reply-To: <9D7432A2-6D8A-11D6-8C51-00039357A82A@extremenetworks.com> References: <71.1fbdea5c.2a1c3904@aol.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 At 09:48 AM 5/22/2002 -0400, RJ Atkinson wrote: > >On Tuesday, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote: > >> To all, >> >> Following the discussion in the interim meeting, I would offer the >> following ideas for the Resource-priority header: > >While protocol design can be amusing to some, I don't think that is >within the charter for IEprep. Of course the chair can correct me >if he thinks I'm confused... But this SIP Header Extension was a fair portion of the discussion Monday and several ID's from within this group had taken the view that this R-P Header was more of a given (done deal) than Allison thought upon her review during the meeting. Several people were and now are motivated to ensure this piece of signaling is in place to have as a mechanism for the IEPREP group to utilize. I believe this is where Mike is coming from. > >Ran > > >_______________________________________________ >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 May 22 10:35:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04714 for ; Wed, 22 May 2002 10:35:22 -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 KAA28623; Wed, 22 May 2002 10:35: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 KAA28591 for ; Wed, 22 May 2002 10:35:14 -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 KAA04679 for ; Wed, 22 May 2002 10:34:54 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 3DA7467103; Wed, 22 May 2002 11:06:37 -0400 (EDT) Date: Wed, 22 May 2002 10:34:42 -0400 Subject: Re: [Ieprep] Resource priority header Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Mpierce1@aol.com, ieprep@ietf.org To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20020522092545.0173a218@localhost> Message-Id: <0E03DB80-6D91-11D6-8C51-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 22, 2002, at 10:30 , James M. Polk wrote: > At 09:48 AM 5/22/2002 -0400, RJ Atkinson wrote: >> >> On Tuesday, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote: >> >>> To all, >>> >>> Following the discussion in the interim meeting, I would offer the >>> following ideas for the Resource-priority header: >> >> While protocol design can be amusing to some, I don't think that is >> within the charter for IEprep. Of course the chair can correct me >> if he thinks I'm confused... > > But this SIP Header Extension was a fair portion of the discussion > Monday > and several ID's from within this group had taken the view that this R-P > Header was more of a given (done deal) than Allison thought upon her > review > during the meeting. Sounds like the interim meeting strayed from the WG's charter, which is unfortunate if true. Thanks for the clarification. > Several people were and now are motivated to ensure > this piece of signaling is in place to have as a mechanism for the > IEPREP > group to utilize. > > I believe this is where Mike is coming from. That is all fine well and good -- but work relating to SIP extensions needs to be done *inside the WG chartered for SIP* -- and on that WG's mailing list rather than here. This WG is NOT chartered to create extensions to SIP, so any such works needs to move over to the right WG. So my original comment stands, but perhaps is a bit more clear now. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 11:09: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 LAA07613 for ; Wed, 22 May 2002 11:09: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 LAA00822; Wed, 22 May 2002 11:09: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 LAA00747 for ; Wed, 22 May 2002 11:09:37 -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 LAA07494 for ; Wed, 22 May 2002 11:09:15 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 11:08:47 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Mpierce1@aol.com'" , ieprep@ietf.org Subject: RE: [Ieprep] Resource priority header Date: Wed, 22 May 2002 11:08:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201A2.8C2240E0" 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_01C201A2.8C2240E0 Content-Type: text/plain; charset="iso-8859-1" Replies inserted in extract -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Tuesday, May 21, 2002 7:58 PM To: ieprep@ietf.org Subject: [Ieprep] Resource priority header 4. If allowed to be something other than an ordered list, then the IANA Considerations would need to to reworded a bit to say "Within each namespace, the registration MUST indicate if the values represent an ordered set and, if so, the relative precedence levels expressed as an ordered list." Further, I would presume that, if an unordered set were created for some namespace, that there would be no restrictions to adding values. [Gunn, Janet NE] ... Don't forget to add "critic-ecp" to the text in the first paragraph of Annex A. With the addition of a new namespace for IPREP, it seems that the reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS call can't take precedence over a "Flash-Override call in the dsn. I suggest replacing the final paragraph of Annex A with something like the following: [Gunn, Janet NE] ... It depends what you mean by "precedence." If we assume that dsn priority works by pre-emption, and GETS works by queuing (I know I am oversimplifying), I can think of situations in which a queued call will get through, while a pre-emption capable call won't (as well as vice versa). For the namespace q735, the defaults are another issue. The intention was to supported interworking with PSTN in which a SIP portion provides the link between 2 PSTN parts. This header then just provides the place to put the equivalent information from the ISUP messages. In this case, there would not be a default. It simply carries what it gets. At the end, when mapping back to ISUP, undefined values can not be mapped so may be defaulted to the lowest, but I don't see that this needs to be specified here. Perhaps a paragraph added to say something like: [Gunn, Janet NE] ... If the set of values can be unordered, "lowest" may not be meaningful. Since the intention of this namespace is to provide interworking between Q.735.3 entities without interpretation by the SIP proxies, no default in the case of no header or a header with an unknown priority value is required. Each MUST carry the header (or lack thereof) exactly as received. The mapping back to Q.735.3 requires that the namespace be correct and that unknown priority values be discarded or changed to the lowest defined. (Remember to change the definition so that "0" is the highest and "4" is the lowest.) For IEPREP, the job is to add the definition of the namespace. I believe that, while the namespace would be added to support the specific requirements of IEPREP, it is something that exists in a broader context - the public network. Within that network, the new value(s) for IEPREP are in addition to the case of "normal" calls, even if the normal calls never use the Resource-priority header. It seems necessary to actually define a "Normal" priority value, simply to be able to say that something defaults to it. [Gunn, Janet NE] Here you seemto be referring to "Normal" as a value/priority within the IEPREP namespace, but below you seem to be referring to "Normal" as a value within the "public_network" namespace. I think I understand why you want it in the former, but I am not sure why you want the "public_network" namespace. Also, the idea has been raised before about the desire to have several values of priority for authorized emergency. (I mean ascending levels of priority, not labels that have no specific meaning.) Also, while 911 emergency type calls may be indicated by another means ("SOS"), it seems that there still is a need to include a priority level in this set for it. Otherwise, it is not straightforward to specify relative priority handling. Therefore, I would propose to add an Annex C as follows (where the actual name of the namespace is open for discussion): ---------------------------------------------------------------------------- ------------------------------------------------ C Namespace public_network The namespace "public_network" is registered here to be used by those public networks which support the emergency services defined in [IEPS/SOS/911/etc]. The namespace contains the following five priority values in ascending order: Normal (Although all normal calls are expected to not contain this header, the value is defined for completeness and to allow the specification of the default.) Emergency_public (Although public emergency calls may be indicated by other means, e.g., "SOS", this value is defined for completeness and to allow sufficient definition of its relationship to the higher priority levels.) Emergency_auth_1 (The assignment and use of this priority level is the responsibility of the network operator/telecommunications agency in the country, etc. Emergency_auth_2 " Emergency_auth_3 " Within a network which is expected to support only this one namespace, when the Resource-priority header is missing or is present but contains an unknown priority value, any procedures applied SHOULD be the same as if the lowest value (Normal) had been specified. When the Resource-priority header contains an unknown namespace, the receiver SHOULD reject the request in which the Resource-priority header was included. [Gunn, Janet NE] It seems to me that what to do with an unknown namespace is a policy issue which should be determined by the network "owner" in negotiation with its customers. [Gunn, Janet NE] There was some discussion of interworking with GSM which, according to various descriptions has 7 or 15 priority levels. I understand from recent e-mails, that it has 7, as I included in my presentation. The 15 levels also referred to are not priority levels as Janet Gunn explained., but rather access classes which can be turned on or off by the service provider to allow certain groups of handsets to get service. As such, they are not "priority levels" and they do not need to be passed anywhere for interworking. The Resource-priority header would only need to deal with the actual 7 priority levels. Do we know what they are called and what interworking might be required? [Gunn, Janet NE] The seven eMLPP priority levels are A,B, 0,1,2,3,4. A and B are reserved for network internal use and are only used locally (within the domain of one MSC (mobile switching center)). 0,1,2,3,4 are offered for subscription, and can be applied globally (ie.e, outside the domain of the originating network). The expected policy is that level 4 is "normal", with no preferential treatment (I am not sure if this is specified in the standard, or just normal operating procedure). Within a given switch, the TREATMENT applied may depend on other characteristics besides eMLPP level. For instance, it is considered good engineering to give preference, in assigning radio channels, to the handover of an existing call over the establishment of a new call. Therefore all the switches in a network MIGHT (and this is an internal policy issue) give a (eMLPP) level 3 "handoff" peferential treatment to a (eMLPP) level 1 "call initiation". Within the switch, this is reflected in what is referred to as an "08.08 priority level". But since this information is not passed between switches, let alone between networks, it should not have any impact on IEPREP. "08.08" has 14 levels. The 15 levels of access overload control apply to access to the control channels (signalling), not access to the traffic channels (bearer, content, voice) . ------_=_NextPart_001_01C201A2.8C2240E0 Content-Type: text/html; charset="iso-8859-1"
Replies inserted in extract
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Tuesday, May 21, 2002 7:58 PM
To: ieprep@ietf.org
Subject: [Ieprep] Resource priority header



4. If allowed to be something other than an ordered list, then the IANA Considerations would need to to reworded a bit to say "Within each namespace, the registration MUST indicate if the values represent an ordered set and, if so, the relative precedence levels expressed as an ordered list." Further, I would presume that, if an unordered set were created for some namespace, that there would be no restrictions to adding values.


[Gunn, Janet NE] ... 

Don't forget to add "critic-ecp" to the text in the first paragraph of Annex A. With the addition of a new namespace for IPREP, it seems that the reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS call can't take precedence over a "Flash-Override call in the dsn. I suggest replacing the final paragraph of Annex A with something like the following:
[Gunn, Janet NE] 
...
 
It depends what  you mean by "precedence."  If we assume that dsn priority works by pre-emption, and GETS works by queuing (I know I am oversimplifying), I can think of situations in which a queued call will get through, while a pre-emption capable call won't (as well as vice versa). 

For the namespace q735, the defaults are another issue. The intention was to supported interworking with PSTN in which a SIP portion provides the link between 2 PSTN parts. This header then just provides the place to put the equivalent information from the ISUP messages. In this case, there would not be a default. It simply carries what it gets. At the end, when mapping back to ISUP, undefined values can not be mapped so may be defaulted to the lowest, but I don't see that this needs to be specified here. Perhaps a paragraph added to say something like:
[Gunn, Janet NE] ...
If the set of values can be unordered, "lowest" may not be meaningful. 

Since the intention of this namespace is to provide interworking between Q.735.3 entities without interpretation by the SIP proxies, no default in the case of no header or a header with an unknown priority value is required. Each MUST carry the header (or lack thereof) exactly as received. The mapping back to Q.735.3 requires that the namespace be correct and that unknown priority values be discarded or changed to the lowest defined.

(Remember to change the definition so that "0" is the highest and "4" is the lowest.)

For IEPREP, the job is to add the definition of the namespace. I believe that, while the namespace would be added to support the specific requirements of IEPREP, it is something that exists in a broader context - the public network. Within that network, the new value(s) for IEPREP are in addition to the case of "normal" calls, even if the normal calls never use the Resource-priority header. It seems necessary to actually define a "Normal" priority value, simply to be able to say that something defaults to it. 
 
[Gunn, Janet NE] Here you seemto be referring to "Normal" as a value/priority within the IEPREP namespace, but below you seem to be referring to "Normal" as a value within the "public_network" namespace.  I think I understand  why you want it in the former, but I am not sure why you want the "public_network" namespace.
 

Also, the idea has been raised before about the desire to have several values of priority for authorized emergency. (I mean ascending levels of priority, not labels that have no specific meaning.)

Also, while 911 emergency type calls may be indicated by another means ("SOS"), it seems that there still is a need to include a priority level in this set for it. Otherwise, it is not straightforward to specify relative priority handling.

Therefore, I would propose to add an Annex C as follows (where the actual name of the namespace is open for discussion):

----------------------------------------------------------------------------------------------------------------------------
C Namespace public_network

The namespace "public_network" is registered here to be used by those public networks which support the emergency services defined in [IEPS/SOS/911/etc]. The namespace contains the following five priority values in ascending order:

Normal (Although all normal calls are expected to not contain this header, the value is defined for completeness and to allow the specification of the default.)
Emergency_public (Although public emergency calls may be indicated by other means, e.g., "SOS", this value is defined for completeness and to allow sufficient definition of its relationship to the higher priority levels.)
Emergency_auth_1 (The assignment and use of this priority level is the responsibility of the network operator/telecommunications agency in the country, etc.
Emergency_auth_2 "
Emergency_auth_3 "

Within a network which is expected to support only this one namespace, when the Resource-priority header is missing or is present but contains an unknown priority value, any procedures applied SHOULD be the same as if the lowest value (Normal) had been specified. When the Resource-priority header contains an unknown namespace, the receiver SHOULD reject the request in which the Resource-priority header was included.
[Gunn, Janet NE] It seems to me that what to do with an unknown namespace is a policy issue which should be determined by the network "owner" in negotiation with its customers. 

[Gunn, Janet NE]  
There was some discussion of interworking with GSM which, according to various descriptions has 7 or 15 priority levels. I understand from recent e-mails, that it has 7, as I included in my presentation. The 15 levels also referred to are not priority levels as Janet Gunn explained., but rather access classes which can be turned on or off by the service provider to allow certain groups of handsets to get service. As such, they are not "priority levels" and they do not need to be passed anywhere for interworking. The Resource-priority header would only need to deal with the actual 7 priority levels. Do we know what they are called and what interworking might be required?
[Gunn, Janet NE] The seven eMLPP priority levels are A,B, 0,1,2,3,4.  A and B are reserved for network internal use and are only used locally (within the domain of one MSC (mobile switching center)). 0,1,2,3,4 are  offered for subscription, and can be applied globally (ie.e, outside the domain of the originating network).  The expected policy is that level 4 is "normal", with no preferential treatment (I am not sure if this is specified in the standard, or just normal operating procedure).
 
Within a given switch, the TREATMENT applied may depend on other characteristics besides eMLPP level.  For instance, it is considered good engineering to give preference, in assigning radio channels, to the handover of an existing call over the establishment of a new call.  Therefore all the switches in a network MIGHT (and this is an internal policy issue) give a (eMLPP) level 3 "handoff" peferential treatment to a (eMLPP) level 1 "call initiation".  Within the switch, this is  reflected in what is referred to as an "08.08 priority level".  But since this information is not passed between switches, let alone between networks, it should not have any impact on IEPREP. "08.08" has 14 levels.
 
The 15 levels of access overload control apply to access to the control channels (signalling), not access to the traffic channels (bearer, content, voice) .



------_=_NextPart_001_01C201A2.8C2240E0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 11:33: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 LAA11571 for ; Wed, 22 May 2002 11:33: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 LAA02965; Wed, 22 May 2002 11:33: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 LAA02934 for ; Wed, 22 May 2002 11:33:30 -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 LAA11485 for ; Wed, 22 May 2002 11:33:09 -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 IAA01829; Wed, 22 May 2002 08:32:55 -0700 (PDT) Message-Id: <4.1.20020522101138.01507540@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 22 May 2002 10:32:47 -0500 To: RJ Atkinson From: "James M. Polk" Subject: Re: [Ieprep] Resource priority header Cc: Mpierce1@aol.com, ieprep@ietf.org In-Reply-To: <0E03DB80-6D91-11D6-8C51-00039357A82A@extremenetworks.com> References: <4.1.20020522092545.0173a218@localhost> 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 10:34 AM 5/22/2002 -0400, RJ Atkinson wrote: > >On Wednesday, May 22, 2002, at 10:30 , James M. Polk wrote: > >> At 09:48 AM 5/22/2002 -0400, RJ Atkinson wrote: >>> >>> On Tuesday, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote: >Sounds like the interim meeting strayed from the WG's charter, >which is unfortunate if true. Thanks for the clarification. Not quite a clear as you might believe in only reading this here. With many IEPREP ID's (Framework, Sec Req, IEPREP Req, RP Req into IEPREP) mentioning the use of signaling within SIP for this potential deferential treatment of a IEPREP communications, there became a need to discuss its status that was not as advanced as was thought based on Allison's concerns. The discussion didn't go into any detail of creating the SIP Header - and little into modifying it -- just how it can be used under IEPREP conditions. > >> Several people were and now are motivated to ensure >> this piece of signaling is in place to have as a mechanism for the >> IEPREP >> group to utilize. >> >> I believe this is where Mike is coming from. > >That is all fine well and good -- but work relating to SIP extensions >needs to be done *inside the WG chartered for SIP* -- and on that WG's >mailing list rather than here. Fair comment -- but its form should be discussed here since this list is referring to it often, and the R-P Header is in several IEPREP ID's. I believe that makes it more on topic than would normally be the case. Fred also asked that more requirements for it be specifically included in IEPREP ID's during the meeting. >This WG is NOT chartered to create >extensions to SIP, so any such works needs to move over to the right WG. If this WG has a specific requirement for the usage of this Header, shouldn't it have a voice in some of the specifics of it? Not everyone on this list is a member (?) of the SIP of SIPPING list > >So my original comment stands, but perhaps is a bit more clear now. > >Ran >rja@extremenetworks.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 May 22 13:09: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 NAA19517 for ; Wed, 22 May 2002 13:09: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 NAA09257; Wed, 22 May 2002 13:08: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 NAA09226 for ; Wed, 22 May 2002 13:08:35 -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 NAA19450 for ; Wed, 22 May 2002 13:08:14 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 5327367103; Wed, 22 May 2002 13:39:59 -0400 (EDT) Date: Wed, 22 May 2002 13:08:03 -0400 Subject: Re: [Ieprep] Resource priority header Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Mpierce1@aol.com, ieprep@ietf.org To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.1.20020522101138.01507540@localhost> Message-Id: <7A69A45E-6DA6-11D6-8C51-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 22, 2002, at 11:32 , James M. Polk wrote: > Fair comment -- but its form should be discussed here since this list is > referring to it often, and the R-P Header is in several IEPREP ID's. I > believe that makes it more on topic than would normally be the case. > Fred > also asked that more requirements for it be specifically included in > IEPREP > ID's during the meeting. Someone mentioning an out-of-scope topic in an I-D does not change or override the charter's language which makes that topic out of scope. In the case you outline, the I-Ds should be edited to remove the out of scope material XOR moved to the appropriate WG. >> This WG is NOT chartered to create >> extensions to SIP, so any such works needs to move over to the right >> WG. > > If this WG has a specific requirement for the usage of this Header, > shouldn't it have a voice in some of the specifics of it? No. Absolutely not. This WG explicitly SHOULD NOT be used to drive requirements onto other WGs. That would violate IETF practices. Individuals who have such proposals to change SIP should be making those proposals in the proper WG -- which is NOT here. > Not everyone on this list is a member (?) of the SIP of SIPPING list SIPPING list is free and open. Anyone not on it that cares about SIP or this conceptual extension should join that list and MOVE THE DISCUSSION over there. That is where the SIP expertise lives and that is where the IETF WG charters says SIP extension proposals/ideas should be worked on -- NOT HERE. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 13:12: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 NAA19756 for ; Wed, 22 May 2002 13:12: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 NAA09453; Wed, 22 May 2002 13:12: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 NAA09417 for ; Wed, 22 May 2002 13:12:13 -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 NAA19719 for ; Wed, 22 May 2002 13:11:52 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 1A4F067103; Wed, 22 May 2002 13:43:37 -0400 (EDT) Date: Wed, 22 May 2002 13:11:41 -0400 Subject: Re: [Ieprep] Resource priority header Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'Mpierce1@aol.com'" , ieprep@ietf.org To: "Gunn, Janet NE" From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 22, 2002, at 11:08 , Gunn, Janet NE wrote: > Replies inserted in extract Please send email to IETF lists in text/plain format, rather than in the text/html that you used in your note. This IS possible even with MS-Outlook by configuring the mail application properly. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 14:09: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 OAA22691 for ; Wed, 22 May 2002 14:09: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 OAA12783; Wed, 22 May 2002 14:08: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 OAA12749 for ; Wed, 22 May 2002 14:08:27 -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 OAA22614 for ; Wed, 22 May 2002 14:07:56 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 14:07:25 -0400 Message-ID: From: "Gunn, Janet NE" To: "'RJ Atkinson'" , "James M. Polk" Cc: Mpierce1@aol.com, ieprep@ietf.org Subject: RE: [Ieprep] Resource priority header Date: Wed, 22 May 2002 14:07:15 -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, The IEPREP charter says: "The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design." Janet -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, May 22, 2002 1:08 PM To: James M. Polk Cc: Mpierce1@aol.com; ieprep@ietf.org Subject: Re: [Ieprep] Resource priority header This WG explicitly SHOULD NOT be used to drive requirements onto other WGs. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 14:33: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 OAA24064 for ; Wed, 22 May 2002 14:33: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 OAA14302; Wed, 22 May 2002 14:33: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 OAA14226 for ; Wed, 22 May 2002 14:33:13 -0400 (EDT) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24040 for ; Wed, 22 May 2002 14:32:50 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v32.5.) id j.103.15b0d102 (3944); Wed, 22 May 2002 14:32:21 -0400 (EDT) Message-ID: <103.15b0d102.2a1d3e35@aol.com> Date: Wed, 22 May 2002 14:32:21 EDT Subject: Re: [Ieprep] Resource priority header To: rja@extremenetworks.com, jmpolk@cisco.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_103.15b0d102.2a1d3e35_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_103.15b0d102.2a1d3e35_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 1:08:43 PM Eastern Daylight Time, rja@extremenetworks.com writes: > This WG explicitly SHOULD NOT be used to drive requirements onto > other WGs. That would violate IETF practices. Individuals who have > such proposals to change SIP should be making those proposals in > the proper WG -- which is NOT here. > Then where should we talk about requirements that might require a change to SIP? We couldn't deal with this issue in SIPPING? Mike --part1_103.15b0d102.2a1d3e35_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 1:08:43 PM Eastern Daylight Time, rja@extremenetworks.com writes:


This WG explicitly SHOULD NOT be used to drive requirements onto
other WGs.  That would violate IETF practices.  Individuals who have
such proposals to change SIP should be making those proposals in
the proper WG -- which is NOT here.


Then where should we talk about requirements that might require a change to SIP? We couldn't deal with this issue in SIPPING?

Mike
--part1_103.15b0d102.2a1d3e35_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 14:37:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24380 for ; Wed, 22 May 2002 14:37: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 OAA14814; Wed, 22 May 2002 14:37: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 OAA14785 for ; Wed, 22 May 2002 14:37:02 -0400 (EDT) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24360 for ; Wed, 22 May 2002 14:36:41 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v32.5.) id i.50.bca21fe (3944); Wed, 22 May 2002 14:36:24 -0400 (EDT) Message-ID: <50.bca21fe.2a1d3f28@aol.com> Date: Wed, 22 May 2002 14:36:24 EDT To: K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_50.bca21fe.2a1d3f28_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Ieprep] Re: 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_50.bca21fe.2a1d3f28_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 10:07:07 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > > From: Mpierce1@aol.com > > > > For IEPREP, the job is to add the definition of the namespace. I believe > > that, while the namespace would be added to support the specific > > requirements of IEPREP, it is something that exists in a broader context > > - the public network. Within that network, the new value(s) for IEPREP > > are in addition to the case of "normal" calls, even if the normal calls > > never use the Resource-priority header. It seems necessary to actually > > define a "Normal" priority value, simply to be able to say that something > > defaults to it. > > I'm sorry, but I don't understand what exactly you are saying here. > Sorry, I know it was somewhat contorted. We're trying to define a namespace which is used for a particular environment or network - in this case - in the public network of a country. The network, and therefore the namespace, needs to support what we call IEPREP or ETS, but it must also support normal calls and 911 calls. So it seems to make sense to define a set of priority values in that namespace which includes all these known things in one set. > > > C Namespace public_network > > > > The namespace "public_network" is registered here to be used by those > > public networks which support the emergency services defined in > > [IEPS/SOS/911/etc]. The namespace contains the following five priority > > values in ascending order: > > ugh. I really feel uncomfortable with this. an association of a generic > name like "public_network" with a distinct number of priority values > really doesn't seem to be desireable. I feel more comfortable starting > out with "known" namespaces or levels like MLPP and IEPS/GETS. my > udnerstanding is that the ITU will define ETS with 5 levels. and there > is e-MLPP with the 15, and GTPS with 3. but some generic and encompassing > I said that the name "public_network" is open for a better choice. Yes, ITU might define ETS with 5 levels (normal plus 4?). My effort is to get "them" and "us" to do the same thing. Another clarification that I tried to make: e-MLPP for GSM does not have 15 levels - it has 7. And yes, if different countries are likely to have different schemes for their brand of ETS (e.g., number of levels), then that is a reason to not add this to the current Resource-priority draft and let that draft be progressed by SIPPING/SIP without it. > > > my 2 pence, > > -ken > > Thanks for the comments. Mike --part1_50.bca21fe.2a1d3f28_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 10:07:07 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes:


> From: Mpierce1@aol.com
>
> For IEPREP, the job is to add the definition of the namespace. I believe
> that, while the namespace would be added to support the specific
> requirements of IEPREP, it is something that exists in a broader context
> - the public network. Within that network, the new value(s) for IEPREP
> are in addition to the case of "normal" calls, even if the normal calls
> never use the Resource-priority header. It seems necessary to actually
> define a "Normal" priority value, simply to be able to say that something
> defaults to it.

I'm sorry, but I don't understand what exactly you are saying here.  


Sorry, I know it was somewhat contorted. We're trying to define a namespace which is used for a particular environment or network - in this case - in the public network of a country. The network, and therefore the namespace, needs to support what we call IEPREP or ETS, but it must also support normal calls and 911 calls. So it seems to make sense to define a set of priority values in that namespace which includes all these known things in one set.


> C Namespace public_network
>
> The namespace "public_network" is registered here to be used by those
> public networks which support the emergency services defined in
> [IEPS/SOS/911/etc]. The namespace contains the following five priority
> values in ascending order:

ugh.  I really feel uncomfortable with this.  an association of a generic
name like "public_network" with a distinct number of priority values
really doesn't seem to be desireable.  I feel more comfortable starting
out with "known" namespaces or levels like MLPP and IEPS/GETS.  my
udnerstanding is that the ITU will define ETS with 5 levels.  and there
is e-MLPP with the 15, and GTPS with 3.  but some generic and encompassing
as "public_network" shouldn't be defined at this time.



I said that the name "public_network" is open for a better choice. Yes, ITU might define ETS with 5 levels (normal plus 4?). My effort is to get "them" and "us" to do the same thing. Another clarification that I tried to make: e-MLPP for GSM does not have 15 levels - it has 7. And yes, if different countries are likely to have different schemes for their brand of ETS (e.g., number of levels), then that is a reason to not add this to the current Resource-priority draft and let that draft be progressed by SIPPING/SIP without it.




my 2 pence,

-ken


Thanks for the comments.

Mike --part1_50.bca21fe.2a1d3f28_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 14: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 OAA24402 for ; Wed, 22 May 2002 14: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 OAA14959; Wed, 22 May 2002 14:37: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 OAA14873 for ; Wed, 22 May 2002 14:37: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 OAA24366 for ; Wed, 22 May 2002 14:37:01 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v32.5.) id r.1ad.2a11f37 (3944); Wed, 22 May 2002 14:36:32 -0400 (EDT) Message-ID: <1ad.2a11f37.2a1d3f30@aol.com> Date: Wed, 22 May 2002 14:36:32 EDT Subject: Re: [Ieprep] Resource priority header To: Janet.Gunn@DynCorp.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1ad.2a11f37.2a1d3f30_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_1ad.2a11f37.2a1d3f30_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 11:09:42 AM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: More replies inserted. > Replies inserted in extract > > >> -----Original Message----- >> From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] >> Sent: Tuesday, May 21, 2002 7:58 PM >> To: ieprep@ietf.org >> Subject: [Ieprep] Resource priority header >> >> >> >> >> >> Don't forget to add "critic-ecp" to the text in the first paragraph of >> Annex A. With the addition of a new namespace for IPREP, it seems that the >> reference to using "critic-ecp" for GETS is incorrect. I'm sure that a >> GETS call can't take precedence over a "Flash-Override call in the dsn. I >> suggest replacing the final paragraph of Annex A with something like the >> following: >> [Gunn, Janet NE] >> ... >> >> It depends what you mean by "precedence." If we assume that dsn priority >> works by pre-emption, and GETS works by queuing (I know I am >> oversimplifying), I can think of situations in which a queued call will >> get through, while a pre-emption capable call won't (as well as vice >> versa). > [Mike Pierce] If a dsn switch could apply queuing to a GETS call that it was trying to handle, it would certainly apply the same queuing to a FlashOverride call rather than blocking it. I'm sure the FlashOverride would always get "precedence" over any GETS call. I don't see any GETS call using the "critic-ecp" value, but maybe I'm wrong on its current use. What I see happening is the GETS call (in a network supporting the "public" namespace) might interwork to the dsn with the interworking function providing a locally defined mapping of the "public" namespace" priority values to the values in the dsn. Maybe GETS "gets" mapped to Immediate. Or if there are multiple levels for GETS as in my proposal, they get mapped to multiple dsn levels. > >> >> For the namespace q735, the defaults are another issue. The intention was >> to supported interworking with PSTN in which a SIP portion provides the >> link between 2 PSTN parts. This header then just provides the place to put >> the equivalent information from the ISUP messages. In this case, there >> would not be a default. It simply carries what it gets. At the end, when >> mapping back to ISUP, undefined values can not be mapped so may be >> defaulted to the lowest, but I don't see that this needs to be specified >> here. Perhaps a paragraph added to say something like: >> [Gunn, Janet NE] ... >> > [Mike Pierce] In the case of q735, the values are actually ordered but they may be carried through SIP as if they are not. It's the specific mapping function at the end that knows their meaning. One could say "defaults to 4" rather than "to the lowest". > >> >> Since the intention of this namespace is to provide interworking between >> Q.735.3 entities without interpretation by the SIP proxies, no default in >> the case of no header or a header with an unknown priority value is >> required. Each MUST carry the header (or lack thereof) exactly as >> received. The mapping back to Q.735.3 requires that the namespace be >> correct and that unknown priority values be discarded or changed to the >> lowest defined. >> >> (Remember to change the definition so that "0" is the highest and "4" is >> the lowest.) >> >> For IEPREP, the job is to add the definition of the namespace. I believe >> that, while the namespace would be added to support the specific >> requirements of IEPREP, it is something that exists in a broader context - >> the public network. Within that network, the new value(s) for IEPREP are >> in addition to the case of "normal" calls, even if the normal calls never >> use the Resource-priority header. It seems necessary to actually define a >> "Normal" priority value, simply to be able to say that something defaults >> to it. >> >> [Gunn, Janet NE] Here you seem to be referring to "Normal" as a >> value/priority within the IEPREP namespace, but below you seem to be >> referring to "Normal" as a value within the "public_network" namespace. I >> think I understand why you want it in the former, but I am not sure why >> > [Mike Pierce} Not sure of your point. I'm not proposing a separate IPEPREP namespace and "public" namespace. The "public" namespace needs to include priority levels for everything that is in that "space" : normal calls, 911 calls, and GETS calls. > > >> >> Also, the idea has been raised before about the desire to have several >> values of priority for authorized emergency. (I mean ascending levels of >> priority, not labels that have no specific meaning.) >> >> Also, while 911 emergency type calls may be indicated by another means >> ("SOS"), it seems that there still is a need to include a priority level >> in this set for it. Otherwise, it is not straightforward to specify >> relative priority handling. >> >> Therefore, I would propose to add an Annex C as follows (where the actual >> name of the namespace is open for discussion): >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------- >> C Namespace public_network >> >> The namespace "public_network" is registered here to be used by those >> public networks which support the emergency services defined in >> [IEPS/SOS/911/etc]. The namespace contains the following five priority >> values in ascending order: >> >> Normal (Although all normal calls are expected to not contain this header, >> the value is defined for completeness and to allow the specification of >> the default.) >> Emergency_public (Although public emergency calls may be indicated by >> other means, e.g., "SOS", this value is defined for completeness and to >> allow sufficient definition of its relationship to the higher priority >> levels.) >> Emergency_auth_1 (The assignment and use of this priority level is the >> responsibility of the network operator/telecommunications agency in the >> country, etc. >> Emergency_auth_2 " >> Emergency_auth_3 " >> >> Within a network which is expected to support only this one namespace, >> when the Resource-priority header is missing or is present but contains an >> unknown priority value, any procedures applied SHOULD be the same as if >> the lowest value (Normal) had been specified. When the Resource-priority >> header contains an unknown namespace, the receiver SHOULD reject the >> request in which the Resource-priority header was included. >> [Gunn, Janet NE] It seems to me that what to do with an unknown namespace >> is a policy issue which should be determined by the network "owner" in >> negotiation with its customers. > [Mike Pierce] Yes, it certainly is policy. I would be happy not saying anything here about defaults or error treatments. Or take the other route and say "MAY do this or MAY do that." > >> >> There was some discussion of interworking with GSM which, according to >> various descriptions has 7 or 15 priority levels. I understand from recent >> e-mails, that it has 7, as I included in my presentation. The 15 levels >> also referred to are not priority levels as Janet Gunn explained., but >> rather access classes which can be turned on or off by the service >> provider to allow certain groups of handsets to get service. As such, they >> are not "priority levels" and they do not need to be passed anywhere for >> interworking. The Resource-priority header would only need to deal with >> the actual 7 priority levels. Do we know what they are called and what >> interworking might be required? >> [Gunn, Janet NE] The seven eMLPP priority levels are A,B, 0,1,2,3,4. A >> and B are reserved for network internal use and are only used locally >> (within the domain of one MSC (mobile switching center)). 0,1,2,3,4 are >> offered for subscription, and can be applied globally (ie.e, outside the >> domain of the originating network). The expected policy is that level 4 >> is "normal", with no preferential treatment (I am not sure if this is >> specified in the standard, or just normal operating procedure). > [Mike Pierce] So I guess the levels 0 to 4 are just like MLPP and A and B are like the "critic-ecp". It seems that only the 0-4 would have to be considered in any interworking (which I suspect is also the case for "critic-ecp"). > > >> Within a given switch, the TREATMENT applied may depend on other >> characteristics besides eMLPP level. For instance, it is considered good >> engineering to give preference, in assigning radio channels, to the >> handover of an existing call over the establishment of a new call. >> Therefore all the switches in a network MIGHT (and this is an internal >> policy issue) give a (eMLPP) level 3 "handoff" peferential treatment to a >> (eMLPP) level 1 "call initiation". Within the switch, this is reflected >> in what is referred to as an "08.08 priority level". But since this >> information is not passed between switches, let alone between networks, it >> should not have any impact on IEPREP. "08.08" has 14 levels. >> >> The 15 levels of access overload control apply to access to the control >> channels (signalling), not access to the traffic channels (bearer, >> content, voice) . >> > [Mike Pierce] So we need to be sure everyone understands that these "08.08" 14 "levels" and the 15 "levels" for access control have nothing to do with the task at hand in IEPREP. Thanks for the comments. Mike --part1_1ad.2a11f37.2a1d3f30_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 11:09:42 AM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes:

More replies inserted.

Replies inserted in extract

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Tuesday, May 21, 2002 7:58 PM
To: ieprep@ietf.org
Subject: [Ieprep] Resource priority header





Don't forget to add "critic-ecp" to the text in the first paragraph of Annex A. With the addition of a new namespace for IPREP, it seems that the reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS call can't take precedence over a "Flash-Override call in the dsn. I suggest replacing the final paragraph of Annex A with something like the following:
[Gunn, Janet NE]
...

It depends what  you mean by "precedence."  If we assume that dsn priority works by pre-emption, and GETS works by queuing (I know I am oversimplifying), I can think of situations in which a queued call will get through, while a pre-emption capable call won't (as well as vice versa).



[Mike Pierce]
If a dsn switch could apply queuing to a GETS call that it was trying to handle, it would certainly apply the same queuing to a FlashOverride call rather than blocking it. I'm sure the FlashOverride would always get "precedence" over any GETS call. I don't see any GETS call using the "critic-ecp" value, but maybe I'm wrong on its current use.
What I see happening is the GETS call (in a network supporting the "public" namespace) might interwork to the dsn with the interworking function providing a locally defined mapping of the "public" namespace" priority values to the values in the dsn. Maybe GETS "gets" mapped to Immediate. Or if there are multiple levels for GETS as in my proposal, they get mapped to multiple dsn levels.


For the namespace q735, the defaults are another issue. The intention was to supported interworking with PSTN in which a SIP portion provides the link between 2 PSTN parts. This header then just provides the place to put the equivalent information from the ISUP messages. In this case, there would not be a default. It simply carries what it gets. At the end, when mapping back to ISUP, undefined values can not be mapped so may be defaulted to the lowest, but I don't see that this needs to be specified here. Perhaps a paragraph added to say something like:
[Gunn, Janet NE] ...
If the set of values can be unordered, "lowest" may not be meaningful.



[Mike Pierce]
In the case of q735, the values are actually ordered but they may be carried through SIP as if they are not. It's the specific mapping function at the end that knows their meaning. One could say "defaults to 4" rather than "to the lowest".


Since the intention of this namespace is to provide interworking between Q.735.3 entities without interpretation by the SIP proxies, no default in the case of no header or a header with an unknown priority value is required. Each MUST carry the header (or lack thereof) exactly as received. The mapping back to Q.735.3 requires that the namespace be correct and that unknown priority values be discarded or changed to the lowest defined.

(Remember to change the definition so that "0" is the highest and "4" is the lowest.)

For IEPREP, the job is to add the definition of the namespace. I believe that, while the namespace would be added to support the specific requirements of IEPREP, it is something that exists in a broader context - the public network. Within that network, the new value(s) for IEPREP are in addition to the case of "normal" calls, even if the normal calls never use the Resource-priority header. It seems necessary to actually define a "Normal" priority value, simply to be able to say that something defaults to it.

[Gunn, Janet NE] Here you seem to be referring to "Normal" as a value/priority within the IEPREP namespace, but below you seem to be referring to "Normal" as a value within the "public_network" namespace.  I think I understand  why you want it in the former, but I am not sure why you want the "public_network" namespace.



[Mike Pierce}
Not sure of your point. I'm not proposing a separate IPEPREP namespace and "public" namespace. The "public" namespace needs to include priority levels for everything that is in that "space" : normal calls, 911 calls, and GETS calls.




Also, the idea has been raised before about the desire to have several values of priority for authorized emergency. (I mean ascending levels of priority, not labels that have no specific meaning.)

Also, while 911 emergency type calls may be indicated by another means ("SOS"), it seems that there still is a need to include a priority level in this set for it. Otherwise, it is not straightforward to specify relative priority handling.

Therefore, I would propose to add an Annex C as follows (where the actual name of the namespace is open for discussion):

----------------------------------------------------------------------------------------------------------------------------
C Namespace public_network

The namespace "public_network" is registered here to be used by those public networks which support the emergency services defined in [IEPS/SOS/911/etc]. The namespace contains the following five priority values in ascending order:

Normal (Although all normal calls are expected to not contain this header, the value is defined for completeness and to allow the specification of the default.)
Emergency_public (Although public emergency calls may be indicated by other means, e.g., "SOS", this value is defined for completeness and to allow sufficient definition of its relationship to the higher priority levels.)
Emergency_auth_1 (The assignment and use of this priority level is the responsibility of the network operator/telecommunications agency in the country, etc.
Emergency_auth_2 "
Emergency_auth_3 "

Within a network which is expected to support only this one namespace, when the Resource-priority header is missing or is present but contains an unknown priority value, any procedures applied SHOULD be the same as if the lowest value (Normal) had been specified. When the Resource-priority header contains an unknown namespace, the receiver SHOULD reject the request in which the Resource-priority header was included.
[Gunn, Janet NE] It seems to me that what to do with an unknown namespace is a policy issue which should be determined by the network "owner" in negotiation with its customers.



[Mike Pierce]
Yes, it certainly is policy. I would be happy not saying anything here about defaults or error treatments. Or take the other route and say "MAY do this or MAY do that."



There was some discussion of interworking with GSM which, according to various descriptions has 7 or 15 priority levels. I understand from recent e-mails, that it has 7, as I included in my presentation. The 15 levels also referred to are not priority levels as Janet Gunn explained., but rather access classes which can be turned on or off by the service provider to allow certain groups of handsets to get service. As such, they are not "priority levels" and they do not need to be passed anywhere for interworking. The Resource-priority header would only need to deal with the actual 7 priority levels. Do we know what they are called and what interworking might be required?
[Gunn, Janet NE] The seven eMLPP priority levels are A,B, 0,1,2,3,4.  A and B are reserved for network internal use and are only used locally (within the domain of one MSC (mobile switching center)). 0,1,2,3,4 are  offered for subscription, and can be applied globally (ie.e, outside the domain of the originating network).  The expected policy is that level 4 is "normal", with no preferential treatment (I am not sure if this is specified in the standard, or just normal operating procedure).



[Mike Pierce]
So I guess the levels 0 to 4 are just like MLPP and A and B are like the "critic-ecp". It seems that only the 0-4 would have to be considered in any interworking (which I suspect is also the case for "critic-ecp").




Within a given switch, the TREATMENT applied may depend on other characteristics besides eMLPP level.  For instance, it is considered good engineering to give preference, in assigning radio channels, to the handover of an existing call over the establishment of a new call.  Therefore all the switches in a network MIGHT (and this is an internal policy issue) give a (eMLPP) level 3 "handoff" peferential treatment to a (eMLPP) level 1 "call initiation".  Within the switch, this is  reflected in what is referred to as an "08.08 priority level".  But since this information is not passed between switches, let alone between networks, it should not have any impact on IEPREP. "08.08" has 14 levels.

The 15 levels of access overload control apply to access to the control channels (signalling), not access to the traffic channels (bearer, content, voice) .


[Mike Pierce]
So we need to be sure everyone understands that these "08.08" 14 "levels" and the 15 "levels" for access control have nothing to do with the task at hand in IEPREP.

Thanks for the comments.

Mike

--part1_1ad.2a11f37.2a1d3f30_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 14:39:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24489 for ; Wed, 22 May 2002 14:39: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 OAA14866; Wed, 22 May 2002 14:37: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 OAA14825 for ; Wed, 22 May 2002 14:37:04 -0400 (EDT) Received: from imo-m02.mx.aol.com (imo-m02.mx.aol.com [64.12.136.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24362 for ; Wed, 22 May 2002 14:36:45 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m02.mx.aol.com (mail_out_v32.5.) id j.12.1f8f0ef9 (3944); Wed, 22 May 2002 14:36:19 -0400 (EDT) Message-ID: <12.1f8f0ef9.2a1d3f23@aol.com> Date: Wed, 22 May 2002 14:36:19 EDT Subject: Re: [Ieprep] Resource priority header To: rja@extremenetworks.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12.1f8f0ef9.2a1d3f23_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_12.1f8f0ef9.2a1d3f23_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 9:48:55 AM Eastern Daylight Time, rja@extremenetworks.com writes: > On Tuesday, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote: > > > To all, > > > > Following the discussion in the interim meeting, I would offer the > > following ideas for the Resource-priority header: > > While protocol design can be amusing to some, I don't think that is > within the charter for IEprep. Of course the chair can correct me > if he thinks I'm confused... > > Ran > Yes, I would be the first to agree that much of what I wrote is protocol design and doesn't belong in IEPREP, but we've had a Catch-22 here. Proposals in SIP for detailed protocol are bounced (correctly) to SIPPING due to lack of requirements, and attempts to define requirements in SIPPING for the Resource-priority header migrated to IEPREP to add their part, and discussion in IEPREP turned to details of levels required and functionality which can only be clearly defined by the details to be added to the Resource-priority header (which is protocol). I would say that those who want to concentrate on high-level functionality or requirements should ignore the protocol details in my e-mail. Although I agree it's "protocol", the details I propose for a new Annex C are a way to work toward an agreement on the high level stuff too (like number of levels). Just think of my original e-mail as being sent to SIP, SIPPING, and IEPREP for people in each to consider the part they are interested in. But knowing that most everyone that is interested in this subject is one all three e-mail lists, it is only sent on one to save wear-and-tear on your Delete key. And yes, as someone else commented, a lot of the IEPREP meeting was spent talking about this same type of thing. Mike --part1_12.1f8f0ef9.2a1d3f23_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 9:48:55 AM Eastern Daylight Time, rja@extremenetworks.com writes:


On Tuesday, May 21, 2002, at 07:57 , Mpierce1@aol.com wrote:

> To all,
>
> Following the discussion in the interim meeting, I would offer the
> following ideas for the Resource-priority header:

While protocol design can be amusing to some, I don't think that is
within the charter for IEprep.  Of course the chair can correct me
if he thinks I'm confused...

Ran


Yes, I would be the first to agree that much of what I wrote is protocol design and doesn't belong in IEPREP, but we've had a Catch-22 here. Proposals in SIP for detailed protocol are bounced (correctly) to SIPPING due to lack of requirements, and attempts to define requirements in SIPPING for the Resource-priority header migrated to IEPREP to add their part, and discussion in IEPREP turned to details of levels required and functionality which can only be clearly defined by the details to be added to the Resource-priority header (which is protocol). I would say that those who want to concentrate on high-level functionality or requirements should ignore the protocol details in my e-mail. Although I agree it's "protocol", the details I propose for a new Annex C are a way to work toward an agreement on the high level stuff too (like number of levels).

Just think of my original e-mail as being sent to SIP, SIPPING, and IEPREP for people in each to consider the part they are interested in. But knowing that most everyone that is interested in this subject is one all three e-mail lists, it is only sent on one to save wear-and-tear on your Delete key.

And yes, as someone else commented, a lot of the IEPREP meeting was spent talking about this same type of thing.

Mike
--part1_12.1f8f0ef9.2a1d3f23_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 16:21: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 QAA28906 for ; Wed, 22 May 2002 16:21: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 QAA20303; Wed, 22 May 2002 16:21: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 QAA20269 for ; Wed, 22 May 2002 16:21:08 -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 QAA28895 for ; Wed, 22 May 2002 16:20:48 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 16:20:27 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Mpierce1@aol.com'" , K.Carlberg@cs.ucl.ac.uk Cc: ieprep@ietf.org Subject: RE: [Ieprep] Re: Date: Wed, 22 May 2002 16:20:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201CE.168C0100" 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_01C201CE.168C0100 Content-Type: text/plain; charset="iso-8859-1" The term "the public network of a country" makes sense in the straight telephony world, but I am not sure it makes sense in the IP world. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, May 22, 2002 2:36 PM To: K.Carlberg@cs.ucl.ac.uk Cc: ieprep@ietf.org Subject: [Ieprep] Re: In a message dated 5/22/02 10:07:07 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > From: Mpierce1@aol.com > > For IEPREP, the job is to add the definition of the namespace. I believe > that, while the namespace would be added to support the specific > requirements of IEPREP, it is something that exists in a broader context > - the public network. Within that network, the new value(s) for IEPREP > are in addition to the case of "normal" calls, even if the normal calls > never use the Resource-priority header. It seems necessary to actually > define a "Normal" priority value, simply to be able to say that something > defaults to it. I'm sorry, but I don't understand what exactly you are saying here. Sorry, I know it was somewhat contorted. We're trying to define a namespace which is used for a particular environment or network - in this case - in the public network of a country. The network, and therefore the namespace, needs to support what we call IEPREP or ETS, but it must also support normal calls and 911 calls. So it seems to make sense to define a set of priority values in that namespace which includes all these known things in one set. > C Namespace public_network > > The namespace "public_network" is registered here to be used by those > public networks which support the emergency services defined in > [IEPS/SOS/911/etc]. The namespace contains the following five priority > values in ascending order: ugh. I really feel uncomfortable with this. an association of a generic name like "public_network" with a distinct number of priority values really doesn't seem to be desireable. I feel more comfortable starting out with "known" namespaces or levels like MLPP and IEPS/GETS. my udnerstanding is that the ITU will define ETS with 5 levels. and there is e-MLPP with the 15, and GTPS with 3. but some generic and encompassing as "public_network" shouldn't be defined at this time. I said that the name "public_network" is open for a better choice. Yes, ITU might define ETS with 5 levels (normal plus 4?). My effort is to get "them" and "us" to do the same thing. Another clarification that I tried to make: e-MLPP for GSM does not have 15 levels - it has 7. And yes, if different countries are likely to have different schemes for their brand of ETS (e.g., number of levels), then that is a reason to not add this to the current Resource-priority draft and let that draft be progressed by SIPPING/SIP without it. my 2 pence, -ken Thanks for the comments. Mike ------_=_NextPart_001_01C201CE.168C0100 Content-Type: text/html; charset="iso-8859-1"
The term "the public network of a country" makes sense in the straight telephony world, but I am not sure it makes sense in the IP world.
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, May 22, 2002 2:36 PM
To: K.Carlberg@cs.ucl.ac.uk
Cc: ieprep@ietf.org
Subject: [Ieprep] Re:

In a message dated 5/22/02 10:07:07 AM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes:


> From: Mpierce1@aol.com
>
> For IEPREP, the job is to add the definition of the namespace. I believe
> that, while the namespace would be added to support the specific
> requirements of IEPREP, it is something that exists in a broader context
> - the public network. Within that network, the new value(s) for IEPREP
> are in addition to the case of "normal" calls, even if the normal calls
> never use the Resource-priority header. It seems necessary to actually
> define a "Normal" priority value, simply to be able to say that something
> defaults to it.

I'm sorry, but I don't understand what exactly you are saying here.  


Sorry, I know it was somewhat contorted. We're trying to define a namespace which is used for a particular environment or network - in this case - in the public network of a country. The network, and therefore the namespace, needs to support what we call IEPREP or ETS, but it must also support normal calls and 911 calls. So it seems to make sense to define a set of priority values in that namespace which includes all these known things in one set.


> C Namespace public_network
>
> The namespace "public_network" is registered here to be used by those
> public networks which support the emergency services defined in
> [IEPS/SOS/911/etc]. The namespace contains the following five priority
> values in ascending order:

ugh.  I really feel uncomfortable with this.  an association of a generic
name like "public_network" with a distinct number of priority values
really doesn't seem to be desireable.  I feel more comfortable starting
out with "known" namespaces or levels like MLPP and IEPS/GETS.  my
udnerstanding is that the ITU will define ETS with 5 levels.  and there
is e-MLPP with the 15, and GTPS with 3.  but some generic and encompassing
as "public_network" shouldn't be defined at this time.



I said that the name "public_network" is open for a better choice. Yes, ITU might define ETS with 5 levels (normal plus 4?). My effort is to get "them" and "us" to do the same thing. Another clarification that I tried to make: e-MLPP for GSM does not have 15 levels - it has 7. And yes, if different countries are likely to have different schemes for their brand of ETS (e.g., number of levels), then that is a reason to not add this to the current Resource-priority draft and let that draft be progressed by SIPPING/SIP without it.




my 2 pence,

-ken


Thanks for the comments.

Mike
------_=_NextPart_001_01C201CE.168C0100-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 16:37: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 QAA29341 for ; Wed, 22 May 2002 16:37:30 -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 QAA21305; Wed, 22 May 2002 16: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 QAA21269 for ; Wed, 22 May 2002 16:37:14 -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 QAA29317 for ; Wed, 22 May 2002 16:36:53 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 May 2002 21:37:10 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org Subject: Re: [Ieprep] Resource priority header In-reply-to: Your message of "Wed, 22 May 2002 14:36:19 EDT." <12.1f8f0ef9.2a1d3f23@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 May 2002 21:37:08 +0100 Message-ID: <23192.1022099828@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 > Just think of my original e-mail as being sent to SIP, SIPPING, and IEPREP > for people in each to consider the part they are interested in. But knowing > that most everyone that is interested in this subject is one all three > e-mail lists, it is only sent on one to save wear-and-tear on your Delete > key. actually, I'd appreciate it if next time you would cross-post with SIPPING *and* this list. my agreement with Ran stemmed from a concern that an extensive discussion on a *formal* proposed change/augmentation to something like the R-P draft will carry on here and SIPPING will be left out. i can always delete a duplicate. i can't always assume that the right people are on both lists. on the other points, I'm not in quite agreement with Ran, but I won't duplicate the points that others have already made. regards, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 16:55: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 QAA29983 for ; Wed, 22 May 2002 16:55: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 QAA22015; Wed, 22 May 2002 16:54: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 QAA21984 for ; Wed, 22 May 2002 16:54:53 -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 QAA29943 for ; Wed, 22 May 2002 16:54:29 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 May 2002 21:54:44 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: In-reply-to: Your message of "Wed, 22 May 2002 14:36:24 EDT." <50.bca21fe.2a1d3f28@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 May 2002 21:54:42 +0100 Message-ID: <23833.1022100882@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 > Sorry, I know it was somewhat contorted. We're trying to define a namespace > which is used for a particular environment or network - in this case - in > the public network of a country. The network, and therefore the namespace, > needs to support what we call IEPREP or ETS, but it must also support normal > calls and 911 calls. So it seems to make sense to define a set of priority > values in that namespace which includes all these known things in one set. ok, I kinda of suspected that you were revisting the issue of "normal". I'll restate my objection a while back of requiring/expecting the specification of the "normal" value in the Resource-Priority header. its redundant, and therefore in my opinion a waste of cycles. its perfectly fine to state that a given value of a list of 2 or more is treated as default. but "normal" should never be a requiredor expected value also, a small nit, but i don't think there should ever be a namespace called IEPREP. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 19:19: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 TAA07417 for ; Wed, 22 May 2002 19:19: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 TAA29720; Wed, 22 May 2002 19:20:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29684 for ; Wed, 22 May 2002 19:20:03 -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 TAA07399 for ; Wed, 22 May 2002 19:19:42 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g4MNK1J22446; Wed, 22 May 2002 19:20:01 -0400 (EDT) Date: Wed, 22 May 2002 19:20:01 -0400 (EDT) From: Scott Bradner Message-Id: <200205222320.g4MNK1J22446@newdev.harvard.edu> To: jmpolk@cisco.com, rja@extremenetworks.com Subject: Re: [Ieprep] Resource priority header Cc: ieprep@ietf.org, Mpierce1@aol.com In-Reply-To: <7A69A45E-6DA6-11D6-8C51-00039357A82A@extremenetworks.com> 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 WG explicitly SHOULD NOT be used to drive requirements onto > other WGs. this WG was asked by the ADs to provide requirements for a RP header at the last IETF meeting - this was mentioned in both the sipping and ieprep sessions Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 20:04: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 UAA09158 for ; Wed, 22 May 2002 20:04: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 UAA01621; Wed, 22 May 2002 20:04: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 UAA01586 for ; Wed, 22 May 2002 20:04:28 -0400 (EDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09118 for ; Wed, 22 May 2002 20:04:07 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g4N04LS12688; Wed, 22 May 2002 20:04:21 -0400 Message-Id: <200205230004.g4N04LS12688@minotaur.nge.isi.edu> To: Ken Carlberg , mpierce1@aol.com, fred@cisco.com cc: ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com Reply-To: mankin@isi.edu Subject: Re: [Ieprep] Resource priority header In-reply-to: Your message of Wed, 22 May 2002 21:37:08 +0100. <23192.1022099828@cs.ucl.ac.uk> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 May 2002 20:04:21 -0400 From: Allison Mankin 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 Speaking as the AD for SIP and SIPPING, I request that there not be cross-posting to SIPPING now. And IEPREP should be disciplined and defer further discussions of the R-P header mechanism. It needs instead to establish rough consensus that the requirements to which R-P is aimed are the right ones. That discussion did not occur Monday; the WG has not made Henning's document a working group document, and a number of the underlying requirements haven't been roughly resolved (I observed on Mon). Given rough consensus requirements from IEPREP, SIPPING chairs and I think that the SIPPING WG will work from them. Again a goal is to have a disciplined discourse, and now SIP-oriented discipline is added: - How do the requirements trade off against requirements of SIP architecture? For instance, the power to express and register priority namespaces is a major tradeoff against SIP concerns that extensibility can lead to implementation complexity, insecurity, and lack of interoperability. Coupling of a SIP feature to functions outside of SIP such as resource management is a major tradeoff against modularity. - Is SIP the right protocol to accomplish all the functions identified by the requirements? Or just some of them, and others need to be met in another way? - Is it an appropriate feature in SIP architecture for a call request for one call to delay other arriving requests? To cause ongoing calls to be terminated? - Are SIP features to meet the requirements securable for the big-I Internet? (Authorizing, authenticating, maintaining integrity for a service with very strong access control needs). Without answers to questions like these, I don't see how R-P standardization can "follow hot on the heels of the requirements draft," to paraphrase a couple of the messages today. Allison _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 22 20:50: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 UAA10804 for ; Wed, 22 May 2002 20:50: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 UAA03033; Wed, 22 May 2002 20:50: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 UAA03002 for ; Wed, 22 May 2002 20:50:21 -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 UAA10799 for ; Wed, 22 May 2002 20:50:01 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA07309; Wed, 22 May 2002 20:50:12 -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 g4N0oB2i003053 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 May 2002 20:50:11 -0400 (EDT) Message-ID: <3CEC3CAD.30004@cs.columbia.edu> Date: Wed, 22 May 2002 20:49:49 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@isi.edu CC: Ken Carlberg , mpierce1@aol.com, fred@cisco.com, ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com Subject: Re: [Ieprep] Resource priority header References: <200205230004.g4N04LS12688@minotaur.nge.isi.edu> 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 Good questions; let me start the discussion. > - How do the requirements trade off against requirements of SIP > architecture? For instance, the power to express and register > priority namespaces is a major tradeoff against SIP concerns that > extensibility can lead to implementation complexity, insecurity, and > lack of interoperability. The problem is probably somewhat similar to having multiple media types - the more you have, the more negotiation you get. I don't think there's a bright line, but I do think that fewer is better. On the other hand, we do, I believe, have the right requirements that are similar to media types and other name spaces: - reasonable default behavior (don't make the call fail unless you really, really have to) - discovery capability (be able to find out what the other side understands) Another analogy is caller preferences, btw. > Coupling of a SIP feature to functions > outside of SIP such as resource management is a major tradeoff against > modularity. We already do this each time we reach a PSTN gateway. The gateway needs to make choices, given resource limits, whose call it drops, delays or takes. Even doing FCFS is a policy decision, with its own implications. (As for packet queueing, retry behavior, for example, may make this particular one a bad choice.) The R-P mechanism is just a policy input, in addition to other SIP information, including inter alia, my strength of authentication, my identity and associated AAA information, the destination (e.g., 'sos' vs. 1-900-your-future --- obviously, the latter wins, since it produces more revenue for the carrier) or a P-Bribe header. > > - Is SIP the right protocol to accomplish all the functions identified > by the requirements? Or just some of them, and others need to be met > in another way? I really see only one function: provide policy input to the gateway on how to handle this session. > > - Is it an appropriate feature in SIP architecture for a call request for > one call to delay other arriving requests? To cause ongoing calls to > be terminated? The action is a policy decision. SIP calls can already cause all of the actions you describe, based on other information in the SIP request. This just provides a more semantically distinct way of expressing user desires, as opposed to overloading other information. ("It's Bill Clinton calling, so it must be high priority, even if the address is lewinsky@aol.com") > > - Are SIP features to meet the requirements securable for the big-I > Internet? (Authorizing, authenticating, maintaining > integrity for a service with very strong access control needs). Again, this is not fundamentally different from securing any other input into policy mechanisms. As usual, the receiver of a message has to make policy decisions that weigh potential cost of erroneous prioritization either way. This requirement is fairly similar to, for example, (trusted-third-party or first-party) caller identification that is used to rouse somebody from sleep. I do see a requirement that any prioritization information be tightly bound to a message, so that cut-and-paste attacks aren't possible. An attacker shouldn't, for example, be able to "upgrade" the discussions of the cooks discussing KP duty over "we will bomb Russia in 5 minutes" calls. (Oops, maybe they should in that case.) > > Without answers to questions like these, I don't see how R-P > standardization can "follow hot on the heels of the > requirements draft," to paraphrase a couple of the messages today. > > Allison > > > > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 01:26: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 BAA18456 for ; Thu, 23 May 2002 01:26: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 BAA23349; Thu, 23 May 2002 01: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 BAA23317 for ; Thu, 23 May 2002 01:25: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 BAA18442 for ; Thu, 23 May 2002 01:25:36 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-69.cisco.com [128.107.163.69]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4N5PGPj004279 for ; Wed, 22 May 2002 22:25:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20020522212230.01b1c980@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 May 2002 19:28:57 -0500 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Yokohama ID Cutoff 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 Those who have agreed to do drafts for the coming meeting in Yokohama - Let's please get them in by mid-June at the latest, both for mailing list review and for meeting the draft cut-off dates. ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts Administrator Subject: Internet-Draft Cutoff Dates for Yokohama, Japan Date: Wed, 22 May 2002 15:01:20 -0400 Sender: nsyracus@cnri.reston.va.us NOTE: There are two (2) Internet-Draft Cutoff dates June 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 24th, at 09:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 24th will NOT be accepted. July 1st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, July 1st, 2002 at 09:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_54.html ------- End of Forwarded Message _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 06:43:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03546 for ; Thu, 23 May 2002 06:43: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 GAA09203; Thu, 23 May 2002 06:42: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 GAA09169 for ; Thu, 23 May 2002 06:42:01 -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 GAA03530 for ; Thu, 23 May 2002 06:41:41 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 May 2002 11:40:14 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: mankin@isi.edu cc: mpierce1@aol.com, fred@cisco.com, ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com Subject: Re: [Ieprep] Resource priority header In-reply-to: Your message of "Wed, 22 May 2002 20:04:21 EDT." <200205230004.g4N04LS12688@minotaur.nge.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 May 2002 11:40:13 +0100 Message-ID: <822.1022150413@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 without duplicating Henning's earlier comments, I'll just reiterate that the R-P header mechanism is just a means of conveying labels. And thats a requirement that we have as originally discussed in Baker's draft, and an objective stated in the Carlberg draft. Policy determines the actions to be taken on those labels. This separation of policy and label has been discussed in the IEPREP list and WG/BoFs, and the position has been heavily endorsed by the chair. Perhaps I'm mistaken, but my concern is that some of the items you raise seem to deveat from this position. on a different note.. > - Is it an appropriate feature in SIP architecture for a call request for > one call to delay other arriving requests? To cause ongoing calls to > be terminated? so while I'm agnostic as to whether such types of actions should be done, I am concerned if one prevents SIP from just conveying information that could trigger such action (either within IP telephony, or in the PSTN). -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 09:56: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 JAA10467 for ; Thu, 23 May 2002 09:56: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 JAA19573; Thu, 23 May 2002 09:56: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 JAA19540 for ; Thu, 23 May 2002 09:56:13 -0400 (EDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10357 for ; Thu, 23 May 2002 09:55:54 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g4NDu8S13331; Thu, 23 May 2002 09:56:08 -0400 Message-Id: <200205231356.g4NDu8S13331@minotaur.nge.isi.edu> To: Ken Carlberg cc: mankin@isi.edu, ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com Reply-To: mankin@isi.edu Subject: Re: [Ieprep] Resource priority header In-reply-to: Your message of Thu, 23 May 2002 11:40:13 +0100. <822.1022150413@cs.ucl.ac.uk> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 May 2002 09:56:08 -0400 From: Allison Mankin 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, > > without duplicating Henning's earlier comments, I'll just reiterate > that the R-P header mechanism is just a means of conveying labels. > And thats a requirement that we have as originally discussed in > Baker's draft, and an objective stated in the Carlberg draft. > It is very easy to say about strings in SIP that they are labels for some external module, but someone has to evaluate the impact of of such a design for SIP processing. Notable here is that there is a strong impact on the security handling of a SIP message carrying one of these - the requirements for authentication and integrity are especially difficult since it seems likely that intermediaries need to be able to modify or add these labels. There is also an impact on interoperability handling. I didn't say it this way in my other message, but there are major tradeoffs (aka inherent conflicts) in the direction being discussed that SIP and IP telephony entities invoke some local default policy for any label they receive that they don't understand. It's hard to see how this squares in the Internet/heterogeneous deployment world with the IEPREP fundamental requirement of high probability of successful calling. If the real tradeoff is that SIP implementations actually need to understand the majority of labels, then there's impact on SIP processing, in my opinion. > Policy determines the actions to be taken on those labels. This > separation of policy and label has been discussed in the IEPREP list > and WG/BoFs, and the position has been heavily endorsed by the chair. It's a classic separation to use, but I think it has allowed some of the hard issues to be placed under a Hitchhiker's Guide-style Someone Else's Problem Field. > Perhaps I'm mistaken, but my concern is that some of the items you > raise seem to deveat from this position. > If the label has impact on the protocol carrying it, as I've argued above, then the items are not deviant (though it might be more fun be deviant...) - anyway, what I wrote were questions to be discussed... > on a different note.. > > > - Is it an appropriate feature in SIP architecture for a call request for > > one call to delay other arriving requests? To cause ongoing calls to > > be terminated? > > so while I'm agnostic as to whether such types of actions should be done, > I am concerned if one prevents SIP from just conveying information that > could trigger such action (either within IP telephony, or in the PSTN). > Only if the "just conveying" has a really good security and authorization story. Finally, your last sentence raises my antennae about a different distinction: the function of conveying the information from a SIP phone to a PSTN gateway for use in the PSTN, and the function of bridging the information between PSTN gateways across the SIP/IP net, are easier to engineer and secure than the functions in which the information invokes functions in the SIP/IP net. I just spoke with Scott about this and he agreed that guidance to the group to keep them well distinguished (which he has given) may mean the working group should consider motivating distinct solutions. Allison _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 10:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11150 for ; Thu, 23 May 2002 10:09:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20694; Thu, 23 May 2002 10:09: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 KAA20649 for ; Thu, 23 May 2002 10:09:13 -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 KAA11136 for ; Thu, 23 May 2002 10:08:54 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v32.5.) id r.151.e449170 (3943); Thu, 23 May 2002 10:07:23 -0400 (EDT) Message-ID: <151.e449170.2a1e519b@aol.com> Date: Thu, 23 May 2002 10:07:23 EDT Subject: Re: [Ieprep] Re: To: Janet.Gunn@DynCorp.com, K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_151.e449170.2a1e519b_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_151.e449170.2a1e519b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 4:21:03 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: > The term "the public network of a country" makes sense in the straight > telephony world, but I am not sure it makes sense in the IP world. > Yes, I understand that this is a fundamental change in concept for voice over IP, SIP, or using the Internet as the infrastructure for a public "telephone" service. But it seems also that this concept is completely contradictory to the concept of an Emergency Service for which certain individuals are given authority to do something (get precedence) by a government agency. We seem to be at a point where these two concepts are coming against each other. I suspect that the concept I intended, and that I think is needed, would be better expressed as "the public telephone service of a country" which somehow runs on "the global network". If there really is one "global network" for public "telephone" service, then we would have two choices for Resource-priority header: 1. Define one worldwide applicable namespace that includes everything everyone wants (impossible?) 2. Each country or region defines a namespace for use for service for that country or region. This might also need lots of definition of interworking betwen countries, how to handle namespace and value you don't understand, etc. since all these regions need to interwork. I suppose this is one of those areas where the service concepts developed for the current well-structured telephony network may not work on the less-structured IP network. Mike --part1_151.e449170.2a1e519b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 4:21:03 PM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes:


The term "the public network of a country" makes sense in the straight telephony world, but I am not sure it makes sense in the IP world.

Yes, I understand that this is a fundamental change in concept for voice over IP, SIP, or using the Internet as the infrastructure for a public "telephone" service. But it seems also that this concept is completely contradictory to the concept of an Emergency Service for which certain individuals are given authority to do something (get precedence) by a government agency. We seem to be at a point where these two concepts are coming against each other.

I suspect that the concept I intended, and that I think is needed, would be better expressed as "the public telephone service of a country" which somehow runs on "the global network".

If there really is one "global network" for public "telephone" service, then we would have two choices for Resource-priority header:
1. Define one worldwide applicable namespace that includes everything everyone wants (impossible?)
2. Each country or region defines a namespace for use for service for that country or region. This might also need lots of definition of interworking betwen countries, how to handle namespace and value you don't understand, etc. since all these regions need to interwork.

I suppose this is one of those areas where the service concepts developed for the current well-structured telephony network may not work on the less-structured IP network.

Mike

--part1_151.e449170.2a1e519b_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 10:10: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 KAA11191 for ; Thu, 23 May 2002 10:10: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 KAA20829; Thu, 23 May 2002 10:09: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 KAA20670 for ; Thu, 23 May 2002 10:09:14 -0400 (EDT) Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11138 for ; Thu, 23 May 2002 10:08:55 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v32.5.) id i.bb.207111fa (3943); Thu, 23 May 2002 10:07:26 -0400 (EDT) Message-ID: Date: Thu, 23 May 2002 10:07:26 EDT Subject: Re: [Ieprep] Re: To: K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_bb.207111fa.2a1e519e_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_bb.207111fa.2a1e519e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 4:54:36 PM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes: > > Sorry, I know it was somewhat contorted. We're trying to define a > namespace > > which is used for a particular environment or network - in this case - in > > the public network of a country. The network, and therefore the > namespace, > > needs to support what we call IEPREP or ETS, but it must also support > normal > > calls and 911 calls. So it seems to make sense to define a set of > priority > > values in that namespace which includes all these known things in one > set. > > ok, I kinda of suspected that you were revisting the issue of "normal". > I'll restate my objection a while back of requiring/expecting the > specification of the "normal" value in the Resource-Priority header. > its redundant, and therefore in my opinion a waste of cycles. its > perfectly fine to state that a given value of a list of 2 or more is > treated as default. but "normal" should never be a requiredor expected > value > > also, a small nit, but i don't think there should ever be a namespace > called IEPREP. > > -ken > > Good, then we agree to not have a namespace called IEPREP. Yes, my above comment mostly relates to the need to define a "normal" value within this new namespace. I believe you are saying that there should not be a "normal" value defined. I'm thinking about how one would make a statement, either in the ID or in a network's own documentation, of the default treatment (if the header is missing or has an unknown value). It seems appropriate to be able to say something like: "It MUST be treated as if it contained a header with a priority value of ____". I need something to put in that blank. I don't understand your point that it would be "a waste of cyles". Sure, I suppose that any implementation might take some additional "cycles" for every possible value that is defined, but then, if you were worried about processor power to parse out the text string, you would not use text strings in the protocol. And for those who don't want to talk about protocol details here (which we shouldn't), I am trying to settle out the issue of how many values need to be in this namespace and what they are. This isn't really protocol detail, except that SIP has made it into detail by using the actual text string of the name of the value in the protocol. Mike --part1_bb.207111fa.2a1e519e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 4:54:36 PM Eastern Daylight Time, K.Carlberg@cs.ucl.ac.uk writes:


> Sorry, I know it was somewhat contorted. We're trying to define a namespace
> which is used for a particular environment or network - in this case - in
>  the public network of a country. The network, and therefore the namespace,
> needs to support what we call IEPREP or ETS, but it must also support normal
> calls and 911 calls. So it seems to make sense to define a set of priority
> values in that namespace which includes all these known things in one set.

ok, I kinda of suspected that you were revisting the issue of "normal".
I'll restate my objection a while back of requiring/expecting the
specification of the "normal" value in the Resource-Priority header.  
its redundant, and therefore in my opinion a waste of cycles.  its
perfectly fine to state that a given value of a list of 2 or more is
treated as default.  but "normal" should never be a requiredor expected
value

also, a small nit, but i don't think there should ever be a namespace
called IEPREP.  

-ken



Good, then we agree to not have a namespace called IEPREP.

Yes, my above comment mostly relates to the need to define a "normal" value within this new namespace. I believe you are saying that there should not be a "normal" value defined. I'm thinking about how one would make a statement, either in the ID or in a network's own documentation, of the default treatment (if the header is missing or has an unknown value). It seems appropriate to be able to say something like: "It MUST be treated as if it contained a header with a priority value of ____". I need something to put in that blank.

I don't understand your point that it would be "a waste of cyles". Sure, I suppose that any implementation might take some additional "cycles" for every possible value that is defined, but then, if you were worried about processor power to parse out the text string, you would not use text strings in the protocol.

And for those who don't want to talk about protocol details here (which we shouldn't), I am trying to settle out the issue of how many values need to be in this namespace and what they are. This isn't really protocol detail, except that SIP has made it into detail by using the actual text string of the name of the value in the protocol.

Mike

--part1_bb.207111fa.2a1e519e_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 10:44:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12771 for ; Thu, 23 May 2002 10:44:56 -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 KAA23038; Thu, 23 May 2002 10:44: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 KAA23005 for ; Thu, 23 May 2002 10:44:29 -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 KAA12764 for ; Thu, 23 May 2002 10:44:09 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06947; Thu, 23 May 2002 10:44:17 -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 g4NEiG2i029139 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 May 2002 10:44:17 -0400 (EDT) Message-ID: <3CED002A.8050700@cs.columbia.edu> Date: Thu, 23 May 2002 10:43:54 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Janet.Gunn@DynCorp.com, K.Carlberg@cs.ucl.ac.uk, ieprep@ietf.org Subject: Re: [Ieprep] Re: References: <151.e449170.2a1e519b@aol.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 The crucial part here is authentication and authorization. Just having a name that's recognized by the remote end is not the difficult or important part - the remote end has to be able to verify that the session setup message is indeed authorized to use that label. Thus, the likely limitation to scaling isn't going to be agreeing on labels, but a "roaming" authentication infrastructure. We have two cases: - The call originates on the PSTN, traverses an IP cloud and then lands at another gateway. If the terminating gateway provider trusts the originating gateway, priority mechanisms can be activated. Unless the number of schemes is counted in the dozens, keeping a table that maps a few different namespaces is not going to be hard, as long as the lists don't change on a monthly basis. I see no reason why they should; government bureaucracy acts as a natural braking agent here that limits the rate of change. - The call originates on an IP phone and reaches a PSTN gateway, possibly and probably through a proxy. The message needs to be properly authenticated, either by the originator or using some kind of third-party authentication as is being discussed in the SIP WG. Again, the likely scaling limit is the cross-domain authentication, not the size of a table. For the latter case, I suspect that we'll get something similar to today, where only certain carriers support GETS, say. If you happen to be on a payphone operated by "COCOTS rip-off & swindle LD disservice", you will have to get to the established carriers that know about you and your privileges by dialing their 1010 carrier code or 800 number. In the case of an IP phone, this will likely mean the use of the Yu draft ("cic") combined with a tel URL. In summary, I think the notion of a global telephone system is a distraction. It doesn't exist today, as far as priority treatment is concerned. Mpierce1@aol.com wrote: > In a message dated 5/22/02 4:21:03 PM Eastern Daylight Time, > Janet.Gunn@DynCorp.com writes: > > >> The term "the public network of a country" makes sense in the straight >> telephony world, but I am not sure it makes sense in the IP world. > > > Yes, I understand that this is a fundamental change in concept for voice > over IP, SIP, or using the Internet as the infrastructure for a public > "telephone" service. But it seems also that this concept is completely > contradictory to the concept of an Emergency Service for which certain > individuals are given authority to do something (get precedence) by a > government agency. We seem to be at a point where these two concepts are > coming against each other. > > I suspect that the concept I intended, and that I think is needed, would > be better expressed as "the public telephone service of a country" which > somehow runs on "the global network". > > If there really is one "global network" for public "telephone" service, > then we would have two choices for Resource-priority header: > 1. Define one worldwide applicable namespace that includes everything > everyone wants (impossible?) > 2. Each country or region defines a namespace for use for service for > that country or region. This might also need lots of definition of > interworking betwen countries, how to handle namespace and value you > don't understand, etc. since all these regions need to interwork. > > I suppose this is one of those areas where the service concepts > developed for the current well-structured telephony network may not work > on the less-structured IP network. > > Mike > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 10:58: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 KAA13307 for ; Thu, 23 May 2002 10:58: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 KAA23966; Thu, 23 May 2002 10:58: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 KAA23930 for ; Thu, 23 May 2002 10:58: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 KAA13302 for ; Thu, 23 May 2002 10:57:58 -0400 (EDT) Received: from FRED-W2K6.cisco.com (rtp-vpn1-53.cisco.com [10.82.224.53]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4NEvhPJ008798 for ; Thu, 23 May 2002 07:57:45 -0700 (PDT) Message-Id: <5.1.0.14.2.20020523073658.02747130@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 07:57:42 -0700 To: ieprep@ietf.org From: Fred Baker Subject: Re: [Ieprep] Resource priority header In-Reply-To: <822.1022150413@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 Maybe we need to raise the level of this conversation. We seem to be focused pretty heavily on specifying a question for the RP draft to be an answer to (which ignores H.323 and so on). May I attempt to rephrase the question without presuming the answer? It seems that the fundamental issue is that during certain circumstances there is a need to ensure that individuals that have been given specific responsibility and authority to act for the good of the community can communicate. These include certain government officials, folks responsible for critical communication infrastructure, those who would organize appropriate responses to mass injury or destruction, etc. In order to accomplish that, policies must be put in place to identify such individuals, verify that communications which claim that privilege are in fact authentically authorized to use it, and ensure that the speed and accuracy of those communications is not unnecessarily impeded. That fact is fundamental to the charter of this working group. In order to accomplish that, there must be mechanisms in the signaling protocols that apply to communications that allow for this type of policy to be identified, claimed, and acted out. These include at minimum SIP, H.323, and H.248; it may well also apply to other signaling protocols, and may apply at other communication layers to non-signalled traffic. The specifics of such a policy are not the province of this working group, or of the IETF in general. However, any such policy which is in active use and which is agreed to by appropriate policy bodies should be representable in the mechanism we define. If this is not so, the failure is not on the part of the policy, it is on the part of the mechanism. From my perspective, the policy belongs to the policy-maker; the language that defines it is non-technical, and should neither attempt nor be construed to color the technical implementation of it. If we can come up with one set of labels that adequately describes all potential policies, this is good. If we cannot (and it seems to me to be a difficult thing, given the possible range of "all potential policies"), then we need to be able to identify both the policy and the claims being made under it. The authentication and authorization mechanisms appropriate are often set by the policy itself; the relevant technical issues in that area include ensuring that mechanisms exist to authenticate and authorize the claims under the policy, giving guidance as to what technical mechanisms may be appropriate or inappropriate, and ensuring that any appropriate mechanism can be encoded in the mechanism provided. The specific set of policies in view here are those used by the US and UK, and which have made their way into existing telephony standards. Other policies are also possible. Once such a mechanism exists, it is also usable by non-emergency-related policies as well, such as the one used by the US military and NATO countries. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 11:25: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 LAA14499 for ; Thu, 23 May 2002 11:25: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 LAA26853; Thu, 23 May 2002 11:25: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 LAA26822 for ; Thu, 23 May 2002 11:25:05 -0400 (EDT) Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14483 for ; Thu, 23 May 2002 11:24:45 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v32.5.) id k.194.7706338 (4262); Thu, 23 May 2002 11:24:24 -0400 (EDT) Message-ID: <194.7706338.2a1e63a8@aol.com> Date: Thu, 23 May 2002 11:24:24 EDT Subject: Re: [Ieprep] Resource priority header To: mankin@isi.edu, K.Carlberg@cs.ucl.ac.uk CC: ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_194.7706338.2a1e63a8_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_194.7706338.2a1e63a8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 9:56:57 AM Eastern Daylight Time, mankin@isi.edu writes: > Ken, > > > > > without duplicating Henning's earlier comments, I'll just reiterate > > that the R-P header mechanism is just a means of conveying labels. > > And thats a requirement that we have as originally discussed in > > Baker's draft, and an objective stated in the Carlberg draft. > > > > It is very easy to say about strings in SIP that they are labels for > some external module, but someone has to evaluate the impact of > of such a design for SIP processing. Notable here is that there is a > strong impact on the security handling of a SIP message carrying one > of these - the requirements for authentication and integrity are > especially difficult since it seems likely that intermediaries need to > As I said in my presentation, I don't believe the procedures for authentication/authorization are any more difficult or different just because we add the Resource-priority header. One might consider it is a little more important to do A/A, but I don't believe it requires any stronger or different A/A than many other capabilities that SIP includes, like releasing or transferring someone else's call. And I seem to remember several other discussions about the problems of providing security for fields which intermediaries might change. In this case, it is not just any intermediary that can change the Resource-priority header. In the architecture I presented in which each originator has a trusted proxy which provides originating service, that trusted proxy would check the authorization to use a particular priority level and change it, just as it might check the authorization to use lots of other things (which have been subscribed to). So the Resource-priority header does not introduce anything new in this regard. > > There is also an impact on interoperability handling. I didn't > say it this way in my other message, but there are major tradeoffs > (aka inherent conflicts) in the direction being discussed that > SIP and IP telephony entities invoke some local default policy for > any label they receive that they don't understand. It's hard to see > how this squares in the Internet/heterogeneous deployment world with > the IEPREP fundamental requirement of high probability of successful > calling. If the real tradeoff is that SIP implementations actually > need to understand the majority of labels, then there's impact > Here is where there is a major difference of concept of what the "heterogeneous" nature of handling traffic is. It is true that if a device has to be able to understand and correctly process every namespace and value defined (and registered with IANA) then there would be a problem (especially with text encoding). But I believe that, independent of the Resource-priority header, there must be some concept of a VPN, so that when a device (proxy, endpoint, etc) is processing a session setup it has some understanding of which VPN it is a part of. Otherwise, it could not apply the procedures required for that "network". I believe the requirements for DOD (and for any other "network") is that when looking at the Resource-priority header, it expects exactly one namespace and would consider everything else as "unknown" and indicative of some other fault (misrouting). Yes, in some cases, there will be interoperability handling that needs to be defined, but the IETF doesn't need to be concerned with this. The DOD network may provide interworking with other networks, and will specify the appropriate mapping between the dsn namespace values and the values used in that other "public" network. > > > on a different note.. > > > > > - Is it an appropriate feature in SIP architecture for a call request > for > > > one call to delay other arriving requests? To cause ongoing calls to > > > be terminated? > > > > so while I'm agnostic as to whether such types of actions should be done, > > I am concerned if one prevents SIP from just conveying information that > > could trigger such action (either within IP telephony, or in the PSTN). > > > > Only if the "just conveying" has a really good security and > This question bothers me. The main point I've been making in a series of presentations is that the DOD requires the ability to give one call some preferential treatment over another. The DOD can not use SIP if this capability is not supported. However, whether the preferential treatment is in the form of "delaying" one call in preference to another, or causing a call to terminate, this treatment is not a part of SIP. SIP just carries the needed information. > Finally, your last sentence raises my antennae about a different > distinction: the function of conveying the information from a SIP > phone to a PSTN gateway for use in the PSTN, and the function of > bridging the information between PSTN gateways across the SIP/IP > net, are easier to engineer and secure than the functions in which > the information invokes functions in the SIP/IP net. I just spoke > with Scott about this and he agreed that guidance to the group > to keep them well distinguished (which he has given) may mean the > Yes, this is a concern that needs to be adressed - how to be confident that the information is correct and authorized before using it to do something within the SIP/IP net. This again is the point of presuming a particular network architecture to provide the trust relationships. For example, when a priority value is received from the PSTN (probably using ISUP) via a gateway, it must be presumed that the PSTN has determined the authenticity of the request. There is then no issue for the SIP/IP net to believe the value and act on it. > Allison > > Mike Pierce --part1_194.7706338.2a1e63a8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 9:56:57 AM Eastern Daylight Time, mankin@isi.edu writes:


Ken,

>
> without duplicating Henning's earlier comments, I'll just reiterate
> that the R-P header mechanism is just a means of conveying labels.
> And thats a requirement that we have as originally discussed in
> Baker's draft, and an objective stated in the Carlberg draft.
>

It is very easy to say about strings in SIP that they are labels for
some external module, but someone has to evaluate the impact of
of such a design for SIP processing. Notable here is that there is a
strong impact on the security handling of a SIP message carrying one
of these - the requirements for authentication and integrity are
especially difficult since it seems likely that intermediaries need to
be able to modify or add these labels.


As I said in my presentation, I don't believe the procedures for authentication/authorization are any more difficult or different just because we add the Resource-priority header. One might consider it is a little more important to do A/A, but I don't believe it requires any stronger or different A/A than many other capabilities that SIP includes, like releasing or transferring someone else's call.

And I seem to remember several other discussions about the problems of providing security for fields which intermediaries might change. In this case, it is not just any intermediary that can change the Resource-priority header. In the architecture I presented in which each originator has a trusted proxy which provides originating service, that trusted proxy would check the authorization to use a particular priority level and change it, just as it might check the authorization to use lots of other things (which have been subscribed to). So the Resource-priority header does not introduce anything new in this regard.


There is also an impact on interoperability handling.  I didn't
say it this way in my other message, but there are major tradeoffs
(aka inherent conflicts) in the direction being discussed that
SIP and IP telephony entities invoke some local default policy for
any label they receive that they don't understand.  It's hard to see
how this squares in the Internet/heterogeneous deployment world with
the IEPREP fundamental requirement of high probability of successful
calling.  If the real tradeoff is that SIP implementations actually
need to understand the majority of labels, then there's impact
on SIP processing, in my opinion.


Here is where there is a major difference of concept of what the "heterogeneous" nature of handling traffic is. It is true that if a device has to be able to understand and correctly process every namespace and value defined (and registered with IANA) then there would be a problem (especially with text encoding). But I believe that, independent of the Resource-priority header, there must be some concept of a VPN, so that when a device (proxy, endpoint, etc) is processing a session setup it has some understanding of which VPN it is a part of. Otherwise, it could not apply the procedures required for that "network". I believe the requirements for DOD (and for any other "network") is that when looking at the Resource-priority header, it expects exactly one namespace and would consider everything else as "unknown" and indicative of some other fault (misrouting).

Yes, in some cases, there will be interoperability handling that needs to be defined, but the IETF doesn't need to be concerned with this. The DOD network may provide interworking with other networks, and will specify the appropriate mapping between the dsn namespace values and the values used in that other "public" network.



> on a different note..
>
> > - Is it an appropriate feature in SIP architecture for a call request for
> >   one call to delay other arriving requests?  To cause ongoing calls to
> >   be terminated?
>
> so while I'm agnostic as to whether such types of actions should be done,
> I am concerned if one prevents SIP from just conveying information that
> could trigger such action (either within IP telephony, or in the PSTN).
>

Only if the "just conveying" has a really good security and
authorization story.


This question bothers me. The main point I've been making in a series of presentations is that the DOD requires the ability to give one call some preferential treatment over another. The DOD can not use SIP if this capability is not supported. However, whether the preferential treatment is in the form of "delaying" one call in preference to another, or causing a call to terminate, this treatment is not a part of SIP. SIP just carries the needed information.


Finally, your last sentence raises my antennae about a different
distinction:  the function of conveying the information from a SIP
phone to a PSTN gateway for use in the PSTN, and the function of
bridging the information between PSTN gateways across the SIP/IP
net, are easier to engineer and secure than the functions in which
the information invokes functions in the SIP/IP net.  I just spoke
with Scott about this and he agreed that guidance to the group
to keep them well distinguished (which he has given) may mean the
working group should consider motivating distinct solutions.


Yes, this is a concern that needs to be adressed - how to be confident that the information is correct and authorized before using it to do something within the SIP/IP net. This again is the point of presuming a particular network architecture to provide the trust relationships. For example, when a priority value is received from the PSTN (probably using ISUP) via a gateway, it must be presumed that the PSTN has determined the authenticity of the request. There is then no issue for the SIP/IP net to believe the value and act on it.


Allison


Mike Pierce

--part1_194.7706338.2a1e63a8_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 11:37:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15020 for ; Thu, 23 May 2002 11:37: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 LAA28075; Thu, 23 May 2002 11:37: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 LAA28041 for ; Thu, 23 May 2002 11:37: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 LAA14961 for ; Thu, 23 May 2002 11:36:46 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 May 2002 16:36:31 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: mankin@isi.edu cc: ieprep@ietf.org, rohan@cisco.com, dwillis@dynamicsoft.com Subject: Re: [Ieprep] Resource priority header In-reply-to: Your message of "Thu, 23 May 2002 09:56:08 EDT." <200205231356.g4NDu8S13331@minotaur.nge.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 May 2002 16:36:27 +0100 Message-ID: <1416.1022168187@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Hi Allison, > It is very easy to say about strings in SIP that they are labels for > some external module, but someone has to evaluate the impact of > of such a design for SIP processing. Notable here is that there is a > strong impact on the security handling of a SIP message carrying one > of these - the requirements for authentication and integrity are > especially difficult since it seems likely that intermediaries need to > be able to modify or add these labels. yes, we are in agreement with the importance of authentication and authorization. I'm not sure about the likelyhood of intermediaries modifying/adding these labels, but it is interesting headache to ponder. I'm uncertain though if you're asking for an additional security companion document to go with the R-P draft, or an extended discussion in the security section of the R-P draft. and if the former, is there something that Ian Brown needs to add to his security document, or was there something else you had in mind? > There is also an impact on interoperability handling. I didn't > say it this way in my other message, but there are major tradeoffs > (aka inherent conflicts) in the direction being discussed that > SIP and IP telephony entities invoke some local default policy for > any label they receive that they don't understand. It's hard to see > how this squares in the Internet/heterogeneous deployment world with > the IEPREP fundamental requirement of high probability of successful > calling. If the real tradeoff is that SIP implementations actually > need to understand the majority of labels, then there's impact > on SIP processing, in my opinion. ok, I would add some clarification on IEPREP's part by saying that the "high probability of successful calling" is only within the realm of those SIP entities that support the R-P header and the NameSpace that triggers it. so, im my view its not a case of all SIP implementations understanding the majority of labels/namespaces that have been defined. as an example, not all carriers in the US support the NS/EP code point for GETS service, but those that do are ones that have been contracted via an SLA and support the high probability of completion. > If the label has impact on the protocol carrying it, as I've > argued above, then the items are not deviant (though it might be > more fun be deviant...) - anyway, what I wrote were questions to be > discussed... yes, agreed. they're good discussion points. > Finally, your last sentence raises my antennae about a different > distinction: the function of conveying the information from a SIP > phone to a PSTN gateway for use in the PSTN, and the function of > bridging the information between PSTN gateways across the SIP/IP > net, are easier to engineer and secure than the functions in which > the information invokes functions in the SIP/IP net. I just spoke agreed. we made this distinction in the framework document and viewed it in part as both 'low hanging fruit' and as something we'll probably see supported in the near term by vendors. > with Scott about this and he agreed that guidance to the group > to keep them well distinguished (which he has given) may mean the > working group should consider motivating distinct solutions. ok. something to give thought to. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 12:11: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 MAA16462 for ; Thu, 23 May 2002 12:11: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 MAA01749; Thu, 23 May 2002 12:11: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 MAA01718 for ; Thu, 23 May 2002 12:11:44 -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 MAA16455 for ; Thu, 23 May 2002 12:11:23 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 May 2002 17:11:31 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Mpierce1@aol.com cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: In-reply-to: Your message of "Thu, 23 May 2002 10:07:26 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 23 May 2002 17:11:30 +0100 Message-ID: <1474.1022170290@cs.ucl.ac.uk> From: Ken Carlberg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA01719 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 so, when I said before, "I'll restate my objection a while back of requiring/expecting the specification of the "normal" value in the Resource-Priority header.", its the *requiring/expecting* part of anyone that defines a NameSpace that I want to avoid. I'm not in a position to say that you can't specify a "normal" value, I just prefer that it not be there. And I definitely want to avoid anyone else feeling that they must put in a "normal" value. i also feel that the concern about protocol discussion has become a bit too strong, but I'll respond privately about why I prefer "normal" not be there with respect to protocol design. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu May 23 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 RAA27417 for ; Thu, 23 May 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 RAA19471; Thu, 23 May 2002 17:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09701 for ; Thu, 23 May 2002 14:14:47 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21378 for ; Thu, 23 May 2002 14:14:25 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4NIDsuF008002; Thu, 23 May 2002 11:13:54 -0700 (PDT) Received: from dhcp-128-107-163-114.cisco.com (dhcp-128-107-163-114.cisco.com [128.107.163.114]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAE65237; Thu, 23 May 2002 11:14:04 -0700 (PDT) Date: Thu, 23 May 2002 11:10:30 -0700 (Pacific Daylight Time) From: Rohan Mahy To: Mpierce1@aol.com cc: mankin@isi.edu, , , Subject: Re: [Ieprep] Resource priority header In-Reply-To: <194.7706338.2a1e63a8@aol.com> Message-ID: X-X-Sender: rmahy@imop.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 Hi, On Thu, 23 May 2002 Mpierce1@aol.com wrote: > > > > > > without duplicating Henning's earlier comments, I'll just reiterate > > > that the R-P header mechanism is just a means of conveying labels. > > > And thats a requirement that we have as originally discussed in > > > Baker's draft, and an objective stated in the Carlberg draft. > > > > > > > It is very easy to say about strings in SIP that they are labels for > > some external module, but someone has to evaluate the impact of > > of such a design for SIP processing. Notable here is that there is a > > strong impact on the security handling of a SIP message carrying one > > of these - the requirements for authentication and integrity are > > especially difficult since it seems likely that intermediaries need to > > > > As I said in my presentation, I don't believe the procedures for > authentication/authorization are any more difficult or different just because > we add the Resource-priority header. One might consider it is a little more > important to do A/A, but I don't believe it requires any stronger or > different A/A than many other capabilities that SIP includes, like releasing > or transferring someone else's call. > > And I seem to remember several other discussions about the problems of > providing security for fields which intermediaries might change. In this > case, it is not just any intermediary that can change the Resource-priority > header. In the architecture I presented in which each originator has a > trusted proxy which provides originating service, that trusted proxy would > check the authorization to use a particular priority level and change it, > just as it might check the authorization to use lots of other things (which > have been subscribed to). So the Resource-priority header does not introduce > anything new in this regard. I agree that this is not a new problem, but we also haven't come up with a general purpose solution to this problem either. The priority of the end-to-middle and middle-to-end security requirement seems to be approaching the top of the heap now though. > > There is also an impact on interoperability handling. I didn't > > say it this way in my other message, but there are major tradeoffs > > (aka inherent conflicts) in the direction being discussed that > > SIP and IP telephony entities invoke some local default policy for > > any label they receive that they don't understand. It's hard to see > > how this squares in the Internet/heterogeneous deployment world with > > the IEPREP fundamental requirement of high probability of successful > > calling. If the real tradeoff is that SIP implementations actually > > need to understand the majority of labels, then there's impact > > > > Here is where there is a major difference of concept of what the > "heterogeneous" nature of handling traffic is. It is true that if a device > has to be able to understand and correctly process every namespace and value > defined (and registered with IANA) then there would be a problem (especially > with text encoding). But I believe that, independent of the Resource-priority > header, there must be some concept of a VPN, so that when a device (proxy, > endpoint, etc) is processing a session setup it has some understanding of > which VPN it is a part of. Otherwise, it could not apply the procedures > required for that "network". I believe the requirements for DOD (and for any > other "network") is that when looking at the Resource-priority header, it > expects exactly one namespace and would consider everything else as "unknown" > and indicative of some other fault (misrouting). > > Yes, in some cases, there will be interoperability handling that needs to be > defined, but the IETF doesn't need to be concerned with this. The DOD network > may provide interworking with other networks, and will specify the > appropriate mapping between the dsn namespace values and the values used in > that other "public" network. I assume that you could also handle traffic with no resource-priority namespace as "ordinary" low-priority traffic in any of these networks, and that doing so would be a policy decision? thanks, -rohan _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 08:12: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 IAA14867 for ; Tue, 28 May 2002 08:12: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 IAA05298; Tue, 28 May 2002 08:12: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 IAA05266 for ; Tue, 28 May 2002 08:12:52 -0400 (EDT) Received: from stingray.shentel.net (stingray.shentel.net [204.111.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14829 for ; Tue, 28 May 2002 08:12:27 -0400 (EDT) Received: from steves (ha30s348.d.shentel.net [204.111.30.92]) by stingray.shentel.net (8.11.3/8.11.3) with SMTP id g4SCCID05381; Tue, 28 May 2002 08:12:19 -0400 From: "Steve Silverman" To: , Cc: Subject: RE: [Ieprep] MLPP Requirements Date: Tue, 28 May 2002 08:13:16 -0400 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 At the IEPREP interim meeting on May 20th, several people spoke in favor of including the US DOD's requirements for MLPP (Multi-Level Precedence & Preemption) in with the IEPREP requirements. Other people felt that this was specific to the DOD and therefore should not be part of the IETF standards. This would result in the DOD writing their own standard to support this requirement. I think this would make things more difficult for much of the industry. I wanted to point out that priority calling is not just a US DOD requirement. Many of the US allies, such as the NATO countries, Australia, and other nations have the same requirement. This does not apply to a few private networks. The US DOD contracts with every major service provider and there is no reason for this to change just because the technology is changing. This results in most major service providers having to meet these standards in many if not all of their switches. This in turn, means that most (if not all) switch vendors will have to implement these functions. I believe that the IETF has the expertise to do a better job on this work and that one set of standards will result in less confusion and less trouble for the various switch vendors. I believe that integration with GSM (which uses multiple priority levels) is also necessary. I hope that the IEPREP WG will include these requirements in its output. Steve Silverman Houston Associates _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 09:01:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16612 for ; Tue, 28 May 2002 09:01: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 JAA09270; Tue, 28 May 2002 09:01: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 JAA09237 for ; Tue, 28 May 2002 09:01: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 JAA16571 for ; Tue, 28 May 2002 09:00:40 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id B605B67103 for ; Tue, 28 May 2002 09:33:16 -0400 (EDT) Date: Tue, 28 May 2002 09:00:30 -0400 Subject: Re: [Ieprep] MLPP Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.481) 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, May 28, 2002, at 08:13 , Steve Silverman wrote: > I wanted to point out that priority calling is not just a US DOD > requirement. Many of the US allies, such as the NATO countries, > Australia, > and other nations have the same requirement. 1) The IETF is a *global* standards body, not one just for the US or just for NATO. There was a time, long ago, when that wasn't strictly true, but that time is long since past. 2) Further, the IETF has not yet seen folks from Australia or a number of other NATO countries speak up *here* about what their requirements are. So while your comment is interesting, it doesn't justify putting what (at the moment, given that the other countries you mention aren't participating directly *here* and telling us *directly* about their requirements) are US-centric requirements into a global standard. And beyond that, there are a lot more countries that you don't claim to be in the set with similar requirements to US DoD than you claim to be in the set. 3) The Japanese description of their requirements/uses for IEPREP services vary significantly from US DoD's description, based on the Japanese presentations at past IETF meetings. > This does not apply to a few > private networks. The US DOD contracts with every major service > provider At least some service providers consider themselves "major" and yet do not have a US DoD contract of this sort. > and there is no reason for this to change just because the technology is > changing. This results in most major service providers having to meet > these > standards in many if not all of their switches. > This in turn, means that most (if not all) switch vendors will have to > implement > these functions. Actually, it means that many of the switch vendors *who sell to the US market* might decide to support the US DoD requirements. That still does not justify putting US-centric requirements into a global standard. Ran rja@extremenetworks.com PS: I'm starting to wonder how many folks on this list (other than me) are *not* having their participation sponsored/paid for by the US Government. IETF *does* frown on having any organisation, including DISA/NCS, try to pack an IETF WG with its supporters to try to dominate the results of the WG. PPS: IETF doesn't vote precisely so that attempts to "stack the deck" won't work. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 09:07: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 JAA16962 for ; Tue, 28 May 2002 09:07: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 JAA10222; Tue, 28 May 2002 09:07: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 JAA10186 for ; Tue, 28 May 2002 09:07:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16926 for ; Tue, 28 May 2002 09:07:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20401; Tue, 28 May 2002 09:07:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA22321; Tue, 28 May 2002 09:07:09 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 May 2002 09:07:09 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B53C6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'RJ Atkinson'" , ieprep Subject: RE: [Ieprep] MLPP Requirements Date: Tue, 28 May 2002 09:07:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Ran I work for a company that is UK based, and has major development activities in the U.S, U.K., Italy and Germany. It's really hard to figure out what any governmental requirements are for IEPREP at the moment, but I'd say that MLPP is a requirement for at least some systems we anticipate building, and I'd like to keep the requirement. Brian > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Tuesday, May 28, 2002 9:01 AM > To: ieprep > Subject: Re: [Ieprep] MLPP Requirements > > > > On Tuesday, May 28, 2002, at 08:13 , Steve Silverman wrote: > > I wanted to point out that priority calling is not just a US DOD > > requirement. Many of the US allies, such as the NATO countries, > > Australia, > > and other nations have the same requirement. > > 1) The IETF is a *global* standards body, not one just for > the US or > just for NATO. There was a time, long ago, when that > wasn't strictly > true, but that time is long since past. > > 2) Further, the IETF has not yet seen folks from Australia > or a number > of other > NATO countries speak up *here* about what their > requirements are. > So while > your comment is interesting, it doesn't justify putting > what (at > the moment, > given that the other countries you mention aren't participating > directly *here* > and telling us *directly* about their requirements) are > US-centric > requirements > into a global standard. And beyond that, there are a lot more > countries > that you don't claim to be in the set with similar > requirements to > US DoD > than you claim to be in the set. > > 3) The Japanese description of their requirements/uses for IEPREP > services vary > significantly from US DoD's description, based on the Japanese > presentations > at past IETF meetings. > > > This does not apply to a few > > private networks. The US DOD contracts with every major service > > provider > > At least some service providers consider themselves > "major" and yet > do not have a US DoD contract of this sort. > > > and there is no reason for this to change just because the > technology is > > changing. This results in most major service providers > having to meet > > these > > standards in many if not all of their switches. > > > > This in turn, means that most (if not all) switch vendors > will have to > > implement > > these functions. > > Actually, it means that many of the switch vendors *who > sell to the > US market* > might decide to support the US DoD requirements. That still does not > justify > putting US-centric requirements into a global standard. > > Ran > rja@extremenetworks.com > > PS: I'm starting to wonder how many folks on this list > (other than me) > are *not* > having their participation sponsored/paid for by the US > Government. IETF *does* > frown on having any organisation, including DISA/NCS, > try to pack > an IETF WG > with its supporters to try to dominate the results of the WG. > PPS: IETF doesn't vote precisely so that attempts to "stack the deck" > won't work. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 09:20: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 JAA17474 for ; Tue, 28 May 2002 09:20: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 JAA11544; Tue, 28 May 2002 09:20: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 JAA11512 for ; Tue, 28 May 2002 09:20:28 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17450 for ; Tue, 28 May 2002 09:20:02 -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 g4SDKPf06425 for ; Tue, 28 May 2002 14:20:25 +0100 From: "Alistair Munro" To: "'ieprep'" Subject: RE: [Ieprep] MLPP Requirements Date: Tue, 28 May 2002 14:22:32 +0100 Message-ID: <000601c2064a$b980fca0$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 In-Reply-To: <313680C9A886D511A06000204840E1CF030B53C6@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Hi All, I'm in the same position as Brian. I support the inclusion of MLPP for the reasons he gives. It may give a degree of future proofing. 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 > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of Rosen, Brian > Sent: 28 May 2002 14:07 > To: 'RJ Atkinson'; ieprep > Subject: RE: [Ieprep] MLPP Requirements > > > Ran > > I work for a company that is UK based, and has major > development activities in the U.S, U.K., Italy and Germany. > It's really hard to figure out what any governmental > requirements are for IEPREP at the moment, but I'd say that > MLPP is a requirement for at > least some systems we anticipate building, and I'd like to keep > the requirement. > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 11:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21062 for ; Tue, 28 May 2002 11:02: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 LAA20247; Tue, 28 May 2002 11:02:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20216 for ; Tue, 28 May 2002 11:02: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 LAA21055 for ; Tue, 28 May 2002 11:02:17 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id CDFCA67103; Tue, 28 May 2002 11:34:56 -0400 (EDT) Date: Tue, 28 May 2002 11:02:10 -0400 Subject: Re: [Ieprep] MLPP Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep To: "Rosen, Brian" From: RJ Atkinson In-Reply-To: <313680C9A886D511A06000204840E1CF030B53C6@whq-msgusr-02.pit.comms.marconi.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 28, 2002, at 09:07 , Rosen, Brian wrote: > Ran > > I work for a company that is UK based, and has major development > activities in the U.S, U.K., Italy and Germany. It's really > hard to figure out what any governmental requirements are for IEPREP > at the moment, but I'd say that MLPP is a requirement for at > least some systems we anticipate building, and I'd like to keep > the requirement. > > Brian That is a helpful note, but what we *really* need is to have folks from a lot more different countries telephony administrations show up to discuss what their specific actual needs really are. And as I recall, Marconi is also heavily dependent on US DoD money. The IETF has an obligation to consider standards globally, rather than just be US-centric or NATO-centric or (some other subset)-centric as is happening here right now. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 11:18: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 LAA21640 for ; Tue, 28 May 2002 11:18: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 LAA21084; Tue, 28 May 2002 11:18:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21054 for ; Tue, 28 May 2002 11:18:34 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21636 for ; Tue, 28 May 2002 11:18: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 g4SFITf09585; Tue, 28 May 2002 16:18:29 +0100 From: "Alistair Munro" To: "'RJ Atkinson'" , "'Rosen, Brian'" Cc: "'ieprep'" Subject: RE: [Ieprep] MLPP Requirements Date: Tue, 28 May 2002 16:20:37 +0100 Message-ID: <002401c2065b$383f5360$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Hi Ran, I think we have to be very proactive to get input and, maybe, you are being overoptimistic in hoping to get operational input from users who don't need to, (and won't) worry about the underlying technology. The input from Hal Folts is based on international state of the art and practice. At some point the requirements will be more of a burden than a benefit, so I don't think we should spend too much more effort in that direction. I would prefer to work on building the bridge between IEPREP and the users and implementers/developers who can validate the IEPREP output. For example, I will be taking up the drafts, earliest post Yokohama, with people in BAPCO (in the UK) to get some feedback. They will have to be pinned down and made to do it, but I don't think we will get anything more by having them involved now. 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 > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of RJ Atkinson > Sent: 28 May 2002 16:02 > To: Rosen, Brian > Cc: ieprep > Subject: Re: [Ieprep] MLPP Requirements > > > > On Tuesday, May 28, 2002, at 09:07 , Rosen, Brian wrote: > > > Ran > > > > I work for a company that is UK based, and has major development > > activities in the U.S, U.K., Italy and Germany. It's > really hard to > > figure out what any governmental requirements are for IEPREP at the > > moment, but I'd say that MLPP is a requirement for at least some > > systems we anticipate building, and I'd like to keep the > requirement. > > > > Brian > > That is a helpful note, but what we *really* need is to > have folks from a lot more different countries telephony > administrations show up to discuss what their specific actual > needs really are. And as I recall, Marconi is also heavily > dependent on US DoD money. > > The IETF has an obligation to consider standards > globally, rather than just be US-centric or NATO-centric or > (some other > subset)-centric > as is happening here right now. > > Ran > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 11:38: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 LAA22299 for ; Tue, 28 May 2002 11:38: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 LAA22717; Tue, 28 May 2002 11:37: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 LAA22687 for ; Tue, 28 May 2002 11:37: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 LAA22223 for ; Tue, 28 May 2002 11:37:18 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 28 May 2002 16:37:28 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Steve Silverman cc: ieprep , Mpierce1 , mankin Subject: Re: [Ieprep] MLPP Requirements In-reply-to: Your message of "Tue, 28 May 2002 08:13:16 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 May 2002 16:37:27 +0100 Message-ID: <1590.1022600247@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, > At the IEPREP interim meeting on May 20th, several people spoke in favor of > including the US DOD's requirements for MLPP (Multi-Level Precedence & > Preemption) in with the IEPREP requirements. Other people felt that this > was specific to the DOD and therefore should not be part of the IETF > standards. This would result in the DOD writing their own standard to > support this requirement. I think this would make things more difficult for > much of the industry. since I didn't attend the meeting, its not possible for me to try and articulate or explain the objections that were expressed at that time. 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? assuming the requirements are roughly the same, I would imagine that operational experience/input from different organizations would be helpful. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 12:22:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23856 for ; Tue, 28 May 2002 12:22:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26519; Tue, 28 May 2002 12:22: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 MAA26484 for ; Tue, 28 May 2002 12:22:08 -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 MAA23811 for ; Tue, 28 May 2002 12:21:44 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 8D2CC67103; Tue, 28 May 2002 12:54:04 -0400 (EDT) Date: Tue, 28 May 2002 12:21:17 -0400 Subject: Re: [Ieprep] MLPP Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'ieprep'" To: "Alistair Munro" From: RJ Atkinson In-Reply-To: <002401c2065b$383f5360$31281eac@degree2.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 28, 2002, at 11:20 , Alistair Munro wrote: > I think we have to be very proactive to get input Some of us are trying to be. I hope others are/will also doing/do so. > The input from Hal Folts is based on international state of the art and > practice. Maybe it is and maybe it isn't. Right now all we *really* know is that it is the US DoD's (or maybe US+UK's) perspective on that. We don't know that it is really the global perspective at this point. I wish we did know what the global perspective is right now. > I would prefer to work on building the bridge between IEPREP and the > users and implementers/developers who can validate the IEPREP output. > For example, I will be taking up the drafts, earliest post Yokohama, > with people in BAPCO (in the UK) to get some feedback. They will have to > be pinned down and made to do it, but I don't think we will get anything > more by having them involved now. Getting more input clearly would help a lot. Getting input sooner seems better than input later to me. More input also seems better than less input... :-) Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 16:18: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 QAA29869 for ; Tue, 28 May 2002 16:18: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 QAA13200; Tue, 28 May 2002 16:18: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 QAA13159 for ; Tue, 28 May 2002 16:18:42 -0400 (EDT) Received: from stingray.shentel.net (stingray.shentel.net [204.111.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29768 for ; Tue, 28 May 2002 16:18:17 -0400 (EDT) Received: from steves (ha93s710.d.shentel.net [204.111.95.198]) by stingray.shentel.net (8.11.3/8.11.3) with SMTP id g4SKI3D17245; Tue, 28 May 2002 16:18:07 -0400 From: "Steve Silverman" To: "RJ Atkinson" , "ieprep" Subject: RE: [Ieprep] MLPP Requirements Date: Tue, 28 May 2002 16:18:58 -0400 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Ran, How much of the user community should want a function before it is subject to global standardization? What percentage? We don't usually know such things in advance. Most people don't think 3 months in advance let alone 5 years in advance. That's why most standards groups that I have seen are dominated by techies who work for switch vendors and a very few foresighted service providers. Getting user requirements has always been quite difficult. Almost a demonstration of psychic powers :-) In this case, both the US DOD and the GSM communities have indicated a requirement for certain functions. One has indicated that this function is very important to them. Is there any doubt that we would like the Internet to interwork with GSM? Much of Europe will need this function. Even if something is only of interest to North America and Europe, that is a large market that many vendors are interested in. Perhaps even some Japanese vendors. Consider the long discussion on Privacy in SIPPING. What percentage of the user community needs to make anonymous calls? Can I knock on your door while wearing a mask? (Sorry for the digression.) If 10% of the users want something that can be done and are willing to pay for it, should we do it? Or at least write the standards to allow it? Steve Silverman Houston Associates PS. We are all supposed to be experts representing ourselves rather than our companies. At the same time, my efforts are supported by my company who expects to make money out of my efforts. I think this is true for most of the participants on this list. How often do you see someone do something greatly to the disadvantage of their employer. > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of > RJ Atkinson > Sent: Tuesday, May 28, 2002 9:01 AM > To: ieprep > Subject: Re: [Ieprep] MLPP Requirements > > > > On Tuesday, May 28, 2002, at 08:13 , Steve Silverman wrote: > > I wanted to point out that priority calling is not just a US DOD > > requirement. Many of the US allies, such as the NATO countries, > > Australia, > > and other nations have the same requirement. > > 1) The IETF is a *global* standards body, not one just for the US or > just for NATO. There was a time, long ago, when that > wasn't strictly > true, but that time is long since past. > > 2) Further, the IETF has not yet seen folks from Australia or a number > of other > NATO countries speak up *here* about what their requirements are. > So while > your comment is interesting, it doesn't justify putting what (at > the moment, > given that the other countries you mention aren't participating > directly *here* > and telling us *directly* about their requirements) are US-centric > requirements > into a global standard. And beyond that, there are a lot more > countries > that you don't claim to be in the set with similar requirements to > US DoD > than you claim to be in the set. > > 3) The Japanese description of their requirements/uses for IEPREP > services vary > significantly from US DoD's description, based on the Japanese > presentations > at past IETF meetings. > > > This does not apply to a few > > private networks. The US DOD contracts with every major service > > provider > > At least some service providers consider themselves "major" and yet > do not have a US DoD contract of this sort. > > > and there is no reason for this to change just because the technology is > > changing. This results in most major service providers having to meet > > these > > standards in many if not all of their switches. > > > > This in turn, means that most (if not all) switch vendors will have to > > implement > > these functions. > > Actually, it means that many of the switch vendors *who sell to the > US market* > might decide to support the US DoD requirements. That still does not > justify > putting US-centric requirements into a global standard. > > Ran > rja@extremenetworks.com > > PS: I'm starting to wonder how many folks on this list (other than me) > are *not* > having their participation sponsored/paid for by the US > Government. IETF *does* > frown on having any organisation, including DISA/NCS, try to pack > an IETF WG > with its supporters to try to dominate the results of the WG. > PPS: IETF doesn't vote precisely so that attempts to "stack the deck" > won't work. > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 18:09: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 SAA02637 for ; Tue, 28 May 2002 18:09: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 SAA22848; Tue, 28 May 2002 18:09: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 SAA22812 for ; Tue, 28 May 2002 18:09:33 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02609 for ; Tue, 28 May 2002 18:09:07 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 17Cp9n-0001dD-00 for ieprep@ietf.org; Tue, 28 May 2002 18:09:31 -0400 Date: Tue, 28 May 2002 18:09:31 -0400 (EDT) From: Sean Donelan To: ieprep@ietf.org Subject: RE: [Ieprep] MLPP Requirements In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Tue, 28 May 2002, Steve Silverman wrote: > How much of the user community should want a function before it is subject > to global standardization? What percentage? We don't usually know such > things in advance. Most people don't think 3 months in advance let alone 5 The issue with standardizing is it then impedes other user of the same bits for other things people may find useful. So the question remains, must it be universially standardized, or only subject to local negotiations between the carrier of choice and DoD. Otherwise, we end up unsetting all that junk so it doesn't interfere with what we want to do. interface ethernet 0 ip address xxx.xxx.xxx.xxx ip route-cache policy ip policy route-map SET-PREC no ip directed-broadcast ! route-map SET-PREC permit 10 match ip address 160 set ip precedence routine ! access-list 160 permit ip any any precedence priority access-list 160 permit ip any any precedence immediate access-list 160 permit ip any any precedence flash access-list 160 permit ip any any precedence flash-override access-list 160 permit ip any any precedence critical access-list 160 permit ip any any precedence internet access-list 160 permit ip any any precedence network ! _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 18:15: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 SAA02771 for ; Tue, 28 May 2002 18:15: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 SAA23393; Tue, 28 May 2002 18: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 SAA23359 for ; Tue, 28 May 2002 18:15: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 SAA02756 for ; Tue, 28 May 2002 18:15:18 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA25125; Tue, 28 May 2002 18:15:27 -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 g4SMFQ2i028571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 May 2002 18:15:27 -0400 (EDT) Message-ID: <3CF40160.2030406@cs.columbia.edu> Date: Tue, 28 May 2002 18:14:56 -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: Sean Donelan CC: ieprep@ietf.org Subject: Re: [Ieprep] MLPP Requirements 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 There are two separate issues: - The basic mechanism - the various namespaces (such as DoD) I think it would be helpful to keep these separate. For some parts, such as Resource-Priority, there is no great harm of having several namespaces in parallel, as long as the number is small. There is no shortage of identifiers, so if the Republic of Burma wakes up to the need of having emergency priority in a few years, they can add this without being disadvantaged by their late arrival to the working group. This may argue for splitting drafts just to get away from the naming discussions. This discussion seems rather abstract at the moment. Sean Donelan wrote: > On Tue, 28 May 2002, Steve Silverman wrote: > >>How much of the user community should want a function before it is subject >>to global standardization? What percentage? We don't usually know such >>things in advance. Most people don't think 3 months in advance let alone 5 > > > The issue with standardizing is it then impedes other user of the same > bits for other things people may find useful. So the question remains, > must it be universially standardized, or only subject to local > negotiations between the carrier of choice and DoD. Otherwise, we end > up unsetting all that junk so it doesn't interfere with what we want to > do. > > interface ethernet 0 > ip address xxx.xxx.xxx.xxx > ip route-cache policy > ip policy route-map SET-PREC > no ip directed-broadcast > ! > route-map SET-PREC permit 10 > match ip address 160 > set ip precedence routine > ! > access-list 160 permit ip any any precedence priority > access-list 160 permit ip any any precedence immediate > access-list 160 permit ip any any precedence flash > access-list 160 permit ip any any precedence flash-override > access-list 160 permit ip any any precedence critical > access-list 160 permit ip any any precedence internet > access-list 160 permit ip any any precedence network > ! > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 21:08: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 VAA05421 for ; Tue, 28 May 2002 21:08: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 VAA02224; Tue, 28 May 2002 21:08:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02190 for ; Tue, 28 May 2002 21:08:35 -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 VAA05418 for ; Tue, 28 May 2002 21:08:10 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id C14D367103; Tue, 28 May 2002 21:40:48 -0400 (EDT) Date: Tue, 28 May 2002 21:07:58 -0400 Subject: Re: [Ieprep] MLPP Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "ieprep" To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: <83E50C81-72A0-11D6-BF2D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 28, 2002, at 04:18 , Steve Silverman wrote: > How much of the user community should want a function before it is > subject > to global standardization? What percentage? We don't usually know such > things in advance. In the IETF, we often understand the breadth of demand before standardisation. I can't speak for other fora. > Consider the long discussion on Privacy in SIPPING. What percentage of > the > user community needs to make anonymous calls? Can I knock on your door > while wearing a mask? (Sorry for the digression.) IETF has *required* such topics to be discussed and addressed in depth for many many years. And by long-standing IETF policy, those particular topics must be addressed even if a large percentage of the user community doesn't want them. > Or at least write the standards to allow it? Nothing I've said was along the lines of "preclude X". Rather, I've consistently said that "before we require X of *everyone*, we need to see broad support for that X across the globe". It is a fine thing to say "we like to ensure that X isn't prohibited". I haven't seen that comment yet. I've been reading "X must be mandated (of everyone)", which just isn't supported by the limited participation happening here so far. > PS. We are all supposed to be experts representing ourselves rather > than > our companies. Yes, though that isn't precisely what seems to be happening here, sigh. Rather we seem to have a WG primarily paid for by DISA/NCS, that lacks the broad diversity present in the WG handling SIP. For example, the details of whether/how SIP might be altered *ought* be determined *by the SIP community as a whole*, rather than some subset as is happening here. > At > the same time, my efforts are supported by my company who expects to > make > money out of my efforts. I think this is true for most of the > participants > on this list. How often do you > see someone do something greatly to the disadvantage of their employer. Happens pretty regularly in several other IETF WGs that I'm familiar with, because some folks understand that the goal of the IETF is NOT company profit, but instead the health and growth of the Internet. And if that sounds idealistic, yes I am that idealistic about that topic. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue May 28 21:50: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 VAA06503 for ; Tue, 28 May 2002 21:50: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 VAA04726; Tue, 28 May 2002 21:50: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 VAA04692 for ; Tue, 28 May 2002 21:50: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 VAA06474 for ; Tue, 28 May 2002 21:50:13 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 29F2967103; Tue, 28 May 2002 22:22:56 -0400 (EDT) Date: Tue, 28 May 2002 21:50:02 -0400 Subject: Re: [Ieprep] MLPP Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ieprep To: Ken Carlberg From: RJ Atkinson In-Reply-To: <1590.1022600247@cs.ucl.ac.uk> Message-Id: <63F5D3AE-72A6-11D6-BF2D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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, May 28, 2002, at 11:37 , 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? The above would be a helpful approach, IMHO, to the extent it got us above the tree tops of the NCS forest and high enough up that we could address MLPP generically in a way that could fit many countries needs -- recognising that one size does not fit all and that different telephone administrations (e.g. US, JP) do articulate different objectives in their IETF presentations so far. In particular, it is not at all clear to me that each network that supports precedence needs to implement that support in exactly the same manner. So if the requirement could be abstracted a fair bit, as Fred's note of a few days ago suggested, that would seem clever (to me at least). Then another WG (e.g. working on SIP) could take the high-level abstract requirement and translate it into zero or more protocol changes to the protocols in that other WG. In a lot of cases, I suspect that clever re-use of existing Internet mechanisms can solve a lot of the actual needs. I believe Fred's draft talks about this, among other things. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed May 29 09:32: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 JAA16408 for ; Wed, 29 May 2002 09:32: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 JAA13555; Wed, 29 May 2002 09:31: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 JAA13522 for ; Wed, 29 May 2002 09:31:51 -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 JAA16350 for ; Wed, 29 May 2002 09:31:26 -0400 (EDT) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 29 May 2002 14:30:07 +0100 X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #25[UCI] To: Henning Schulzrinne cc: ieprep@ietf.org Subject: Re: [Ieprep] MLPP Requirements In-reply-to: Your message of "Tue, 28 May 2002 18:14:56 EDT." <3CF40160.2030406@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 14:30:07 +0100 Message-ID: <1713.1022679007@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 may argue for splitting drafts just to get away from the naming > discussions. I think it would be a real shame to not include a simple example set of labels in the draft as it exists now. but if it simplifies the process of advancing the mechanism (the mechanism obviously being beyond the scope of this group), then I would concur with the thought of splitting the document. > This discussion seems rather abstract at the moment. quite agreed. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep