From ieprep-bounces@ietf.org Thu Jul 06 13:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXMu-0002a9-Dc; Thu, 06 Jul 2006 13:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXMt-0002Zz-FI for ieprep@ietf.org; Thu, 06 Jul 2006 13:10:23 -0400 Received: from hermes.hosts.co.uk ([212.84.175.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXMs-0005iz-SI for ieprep@ietf.org; Thu, 06 Jul 2006 13:10:23 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1FyXMX-0005db-Gm; Thu, 06 Jul 2006 18:10:04 +0100 In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.us.saic.com> References: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.us.saic.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E779451-D7B3-47B6-8162-8B0719E8255A@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] Another version of a potential IEPREP charter Date: Thu, 6 Jul 2006 13:10:11 -0400 To: "King, Kimberly S." X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.4 (----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org On Jun 12, 2006, at 12:30 PM, King, Kimberly S. wrote: > We were asked to tighten up the potential new charter. Here is a > start. > Comments? A while back there was a suggestion to change the name of the group to a name that included MLPP because it seemed that the new milestones moved away to some degree from the original "emergency" motivation of the group. It was felt that such a move would not be accepted by the IESG, so I'd like to make an attempt to find some middle ground in recognizing the evolution of the group. below are some suggested changes in both the charter name and in the first couple of paragraphs of the previously suggested new charter (I left the rest of the charter intact). Note that the "new" and "old" sections are marked with "< >" tags). While there is precedent in changing WG names, I've been told that it can be a big administrative hassle -- especially with respect to retaining/associating previous archived information. So, we would be bound to the same IEPREP acronym. Finally, you'll notice that the main changes I have suggested is an emphasis on prioritization (which has always been a foundation of this group) and de-emphasizing the word "emergency". comments? -ken ===================================== Internet Prioritization and Preparedness (IEPREP) Charter Internet Emergency Preparedness (ieprep) Charter ---------------------------------- Prioritization involves conveying the importance of communications. Communities of interest have viewed prioritization as one step in facilitating immediate recovery operations during emergencies/ disasters, or in other occasions when resources are at a minimum and particular sets of users (e.g., first responders) have a need to obtain the best available service. Either circumstance may involves communications over the Internet or private IP networks/intranets. Natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, wartime events) may occur at any time. Quick response for recovery operations requires immediate access to any telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support prioritized communications. Actions taken upon prioritized communications vary per interested party. On one hand, traffic engineering or schemas to improve the probability of establishing/maintaining communications during times of distress may prove sufficient. Other groups may have an interest in a more binary approach of displacing or preempting lower priority communications. ---------------------------------- ------------------------------------------------------ Description of Working Group: Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious emergency events including natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, combat situations or wartime events). In addition, related capabilities should be operative in normal command and control operations of military services, which often have timeliness requirements even in peacetime. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. ----------------------------------------------------- The IEPREP WG will address proactive measures to congestion and recovery from various outages using three perspectives: 1. A commercial (i.e., or public) telecommunications infrastructure 2. An enterprise or governmental/military telecommunications infrastructure that retains sole administration of its own network resources 3. A governmental/military telecommunications infrastructure that combines private resources and leverages public infrastructure. Now that the initial documents describing the broad problem space and its salient characteristics have been completed, new efforts will focus on specific requirements and solutions, such as those pertaining to the governmental/military sector. The following are specific examples that can satisfy the interests of governmental/ military (and potentially, commercial/public/enterprise) emergency communications: 1. Under emergency circumstances, some countries require civil networks to distinguish sessions based on the user's indication of precedence. The network can use the precedence information to give priority to some sessions over others, up to and including preemption of lower-precedence sessions. In many countries' governmental networks, the capabilities needed to support precedence-based preferential treatment are requirements on the equipment and services used to build those networks. As Internet-based technology continues to expand into civil and government networks, requirements for precedence-based capabilities will need to be developed. IEPREP will document these requirements as they pertain to technologies of interest to IETF. 2. Specific countries may have additional considerations that define the context in which they implement session precedence and preemption. For example, network ownership constraints (which may differ from commercial deployments), communities of interest including dial-plan considerations, encryption assumptions and any limitations arising from differing security levels, etc. that should be described before mechanisms can be proposed. IEPREP should document the context for implementing solutions. In addition, specific solutions must be developed when appropriate. 3. While voice was the driving application for IEPREP in the past, preferential treatments will need to be applied to all applications essential to emergency communications. Preferential treatment must address robustness of both voice and non-real-time applications that share the same infrastructure. The IEPREP WG should document the preferential treatment mechanisms that are appropriate for any essential communications. In the IETF, considerations for treatment and security of emergency communications stretch across a number of working groups, mostly in the RAI Area, notably including the various voice/video signaling working groups, instant messaging, and QoS signaling. IEPREP will cooperate closely with these groups and with those outside of the IETF such as various ITU-T study groups. In addition, IEPREP will pursue subject matter experts (e.g., security) for specification review if such expertise does not exist within the working group in order to ensure continued high quality specifications. If there is an existing group that can extend a protocol or mechanism, IEPREP will generate only a requirements document for those groups to evaluate. If there is not an existing group that can extend a protocol or mechanism, IEPREP will prepare requirements and discuss the extension of that protocol/mechanism or protocols/ mechanisms within IEPREP. Goals and Milestones: Done Submit initial I-D of Requirements Done Submit initial I-D of Framework Done Submit initial I-D of Recommendations BCP Done Produce an Requirements I-D to IESG for publication as an Informational RFC Done Submit Framework I-D to IESG for publication as an Informational RFC Aug 06 Submit an initial I-D of Requirements of Government/Military Networks for Precedence and Preemption Aug 06 Submit an initial I-D of ETS Terminology. This document should define ieprep related terms (e.g., ETS, GETS, MLPP) and explain their relationships and how they have been used in existing RFCs Sept 06 Submit an initial I-D of Deployment Considerations of Precedence and Preemption on Government/Military Networks. This document should clarify the context that Government/Military requirements must operate. Nov 06 Submit final I-D of Requirements of Government/Military Networks for Precedence and Preemption to IESG for publication as an Informational RFC NOV 06 Submit final I-D of ETS Terminology to IESG for publication as an Informational RFC. Jan 07 Submit an final I-D of Deployment Considerations of Precedence and Preemption on Government/Military Networks to IESG for publication as an Informational RFC. Feb 07 Submit an initial I-D of Mechanisms for Precedence and Preemption to be used by Government/Military Networks Apr 07 Submit final I-D of Mechanisms for Precedence and Preemption to be used by Government/Military Networks to IESG for publication as a BCP Apr 07 The working group will discuss re-chartering if additional efforts are agreed upon by the WG (for example, work items related to protocols outside existing WGs). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 07 13:04:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytkz-0005kN-6z; Fri, 07 Jul 2006 13:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytkx-0005kI-BH for ieprep@ietf.org; Fri, 07 Jul 2006 13:04:43 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fytkw-0008Ce-Op for ieprep@ietf.org; Fri, 07 Jul 2006 13:04:43 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 13:04:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Date: Fri, 7 Jul 2006 13:04:42 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A590C6D08@vanualevu.disanet.disa-u.mil> in-reply-to: <3E779451-D7B3-47B6-8162-8B0719E8255A@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Thread-Index: AcahHxmrev5fFCzZTGOEtxjKjLittQAxihtA From: "Perschau, Stephen CIV NCS NC2" To: "ken carlberg" X-OriginalArrivalTime: 07 Jul 2006 17:04:42.0559 (UTC) FILETIME=[709E7CF0:01C6A1E7] X-Spam-Score: 1.3 (+) X-Scan-Signature: 56904003e9d74831849863e83b1962ec Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE =20 Essentially accept Ken's proposal with some modifications. Still do not like the text that Ken didn't modify so my suggested changes are provided. Hopefully the strikeouts and additions are visible. This proposed text brings the charter in line with the deliverables and makes it clear that the focus is on MLPP for managed IP networks and public networks where permissible by regulations/law. =20 Stephen Perschau =20 =20 --------------------------------------------------------------- ------------------------------ =20 Internet Prioritization and Preparedness (IEPREP) Charter =20 Prioritization involves conveying the importance of communications. Communities of interest have viewed prioritization as one step in facilitating immediate response and recovery operations during emergencies/ disasters, or at times when network resources are stressed possibly due to damage, congestion, denial of service attacks, etc. It is during these types of events that in other occasions when resources are at a minimum and particular sets of users (e.g., first responders authorized users) have a need to obtain the best available service. Either circumstance may involve communications over the Internet or private IP networks/intranets. =20 Natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, wartime events) may occur at any time. Quick response for response and recovery operations requires immediate access to any available telecommunications resources capabilities at hand. These resources capabilities include not only: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs but also access to available network resources (e.g., bandwidth). Because the commercial telecommunications infrastructure is rapidly evolving to Internet-based technology . Therefore, the Internet community needs to consider how its protocols can best support prioritized communications in government/military networks. =20 Actions taken upon prioritized communications vary per interested party. There are different ways to provide prioritization (1) On one hand, traffic engineering or schemas to that improve the probability of establishing/maintaining communications during times of stress, (2) distress may prove sufficient. Other groups may have an interest in a more binary approach of displacing or preempting lower priority communications. =20 --------------------------------------------------------------- ------------------------------ =20 Delete all text beginning with "The IEPREP WG will address proactive measures...." up to the milestones and insert the following replcaement text:=20 =20 =20 ------------------------------------------------------------------- ---------------------------------------- The IEPREP WG will address proactive measures to deal with response and recovery efforts from the following two perspectives: 1. A government/military telecommunications network that retains sole administration control of its own network resources. 2. A government/military telecommunications infrastructure that combines enterprise network resources and leverages public network resources. These new efforts will focus on specific requirements and solutions pertaining to the government/military sector. =20 While voice traffic was the driving application in the past, preferential treatment needs to be applied to all traffic pertaining to response and recovery operations. This includes real-time (e.g., voice, streaming video, etc.) and non-real-time (e.g., text messaging, SMS, etc.) traffic that will be competing for the same network resources as non response and recovery operations traffic. The WG will document the preferential treatment mechanisms that are appropriate for communications used in response and recovery operations. Under certain circumstances, some countries require their networks to distinguish sessions based on the user's indication of precedence. The network can use the precedence information to give priority to some sessions over others, up to and including preemption of lower-precedence sessions. In many countries' government/military networks, the capabilities needed to support precedence-based preferential treatment are requirements on the equipment and services used to build those networks. As Internet-based technology continues to expand into government/military networks, requirements for precedence-based capabilities will need to be developed. The Working Group (WG) will document these requirements as they pertain to technologies of interest to IETF. =20 Some countries have additional considerations that define the context in which they implement session precedence and preemption. For example, network ownership constraints (which may differ from commercial deployments), communities of interest including dial-plan considerations, encryption assumptions, and limitations arising from different security levels, etc. that should be described before mechanisms are proposed. The WG will document the context for implementation solutions. In the IETF, consideration for treatment and security of communications for response and recovery operations stretch across a number of working groups, mostly in the RAI Area, including various working groups involved with voice/video signaling, instant messaging, QoS signaling, etc. The WG will cooperate closely with these groups and with those outside the IETF (e.g., ITU-T Study Groups). To ensure high quality specifications the WG will pursue subject matter expert (e.g., security) for specification review. If there is an existing group that can extend a protocol or mechanism, the IEPREP WG will generate a requirements document for evaluation by the group responsible for the protocol. If there is not an existing group that can extend a protocol or mechanism, the IEPREP WG will prepare requirements and discuss the extension of that protocol/mechanism or protocols/mechanisms within IEPREP. =20 ------------------------------------------------------------------- --------------------------------------,NEW> =20 =20 Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 07 13:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyu95-0004QY-3z; Fri, 07 Jul 2006 13:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyu94-0004QT-Dk for ieprep@ietf.org; Fri, 07 Jul 2006 13:29:38 -0400 Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs100.ncr.disa.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyu94-0001B9-2u for ieprep@ietf.org; Fri, 07 Jul 2006 13:29:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Date: Fri, 7 Jul 2006 13:29:37 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A590C6D09@vanualevu.disanet.disa-u.mil> in-reply-to: <9B4320CC9BC1D847AFFA97F25A422A590C6D08@vanualevu.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Thread-Index: Acah53YmJWVpB+JBQwSQQp+nuxSxRAAAahgA From: "Perschau, Stephen CIV NCS NC2" To: "ken carlberg" X-OriginalArrivalTime: 07 Jul 2006 17:29:37.0664 (UTC) FILETIME=[EBC56800:01C6A1EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Sorry for having to resend this but the text deletions/modifications in Ken's proposed text did not go through as highlighted. Ignore the previous email. Stephen Perschau -----Original Message----- From: Perschau, Stephen CIV NCS NC2=20 Sent: Friday, July 07, 2006 1:05 PM To: ken carlberg Cc: ieprep@ietf.org Subject: RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE =20 Essentially accept Ken's proposal with some modifications. Still do not like the text that Ken didn't modify so my suggested changes are provided. Hopefully the strikeouts and additions are visible. This proposed text brings the charter in line with the deliverables and makes it clear that the focus is on MLPP for managed IP networks and public networks where permissible by regulations/law. =20 Stephen Perschau =20 =20 --------------------------------------------------------------- ------------------------------ Internet Prioritization and Preparedness (IEPREP) Charter Prioritization involves conveying the importance of communications. Communities of interest have viewed prioritization as one step in facilitating response and recovery operations during emergencies/ disasters, or at times when network resources are stressed possibly due to damage, congestion, denial of service attacks, etc. It is during these types of events that particular sets of users (e.g., authorized users) have a need to obtain the best available service. Either circumstance may involve communications over the Internet or private IP networks/intranets. Natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, wartime events) may occur at any time. Quick response for response and recovery operations requires immediate access to available telecommunications resources. These resource include not only: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs but also access to available network resources (e.g., bandwidth). Because telecommunications infrastructures are rapidly evolving to Internet-based technology the Internet community needs to consider how its protocols can support prioritized communications in government/military networks. There are different ways to provide prioritization: (1) traffic engineering or schemas that improve the probability of establishing/maintaining communications during times of stress, or (2) a more binary approach of displacing or preempting lower priority communications. --------------------------------------------------------------- --------------------------- =20 Delete all text beginning with "The IEPREP WG will address proactive measures...." up to the milestones and insert the following replacement text:=20 ------------------------------------------------------------------- ---------------------------------------- The IEPREP WG will address proactive measures to deal with response and recovery efforts from the following two perspectives: 1. A government/military telecommunications network that retains sole administration control of its own network resources. 2. A government/military telecommunications infrastructure that combines enterprise network resources and leverages public network resources. These new efforts will focus on specific requirements and solutions pertaining to the government/military sector. While voice traffic was the driving application in the past, preferential treatment needs to be applied to all traffic pertaining to response and recovery operations. This includes real-time (e.g., voice, streaming video, etc.) and non-real-time (e.g., text messaging, SMS, etc.) traffic that will be competing for the same network resources as non response and recovery operations traffic. The WG will document the preferential treatment mechanisms that are appropriate for communications used in response and recovery operations. Under certain circumstances, some countries require their networks to distinguish sessions based on the user's indication of precedence. The network can use the precedence information to give priority to some sessions over others, up to and including preemption of lower-precedence sessions. In many countries' government/military networks, the capabilities needed to support precedence-based preferential treatment are requirements on the equipment and services used to build those networks. As Internet-based technology continues to expand into government/military networks, requirements for precedence-based capabilities will need to be developed. The Working Group (WG) will document these requirements as they pertain to technologies of interest to IETF. Some countries have additional considerations that define the context in which they implement session precedence and preemption. For example, network ownership constraints (which may differ from commercial deployments), communities of interest including dial-plan considerations, encryption assumptions, and limitations arising from different security levels, etc. that should be described before mechanisms are proposed. The WG will document the context for implementation solutions. In the IETF, consideration for treatment and security of communications for response and recovery operations stretch across a number of working groups, mostly in the RAI Area, including various working groups involved with voice/video signaling, instant messaging, QoS signaling, etc. The WG will cooperate closely with these groups and with those outside the IETF (e.g., ITU-T Study Groups). To ensure high quality specifications the WG will pursue subject matter expert (e.g., security) for specification review. If there is an existing group that can extend a protocol or mechanism, the IEPREP WG will generate a requirements document for evaluation by the group responsible for the protocol. If there is not an existing group that can extend a protocol or mechanism, the IEPREP WG will prepare requirements and discuss the extension of that protocol/mechanism or protocols/mechanisms within IEPREP. ------------------------------------------------------------------- --------------------------------------,NEW> The milestones remain as proposed =20 Classification: UNCLASSIFIED Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 07 17:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyyLG-0000q6-HL; Fri, 07 Jul 2006 17:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyyLF-0000pn-89 for ieprep@ietf.org; Fri, 07 Jul 2006 17:58:29 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyyLD-0005GT-Vz for ieprep@ietf.org; Fri, 07 Jul 2006 17:58:29 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k67LwNsW015590; Fri, 7 Jul 2006 17:58:23 -0400 (EDT) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A590C6D09@vanualevu.disanet.disa-u.mil> Subject: Re: RESEND RE: [Ieprep] Another version of a potential IEPREP charter (UNCLASSIFIED) To: "Perschau, Stephen CIV NCS NC2" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 7 Jul 2006 17:58:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/07/2006 05:57:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ieprep@ietf.org, ken carlberg X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org My comments on the first part. * on the lines I changed Thanks, Janet -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "Perschau, Stephen CIV NCS NC2" wrote on 07/07/2006 01:29:37 PM: > Classification: UNCLASSIFIED > Caveats: NONE > > Sorry for having to resend this but the text deletions/modifications in > Ken's proposed text did not go through as highlighted. Ignore the > previous email. > > Stephen Perschau > > -----Original Message----- > From: Perschau, Stephen CIV NCS NC2 > Sent: Friday, July 07, 2006 1:05 PM > To: ken carlberg > Cc: ieprep@ietf.org > Subject: RE: [Ieprep] Another version of a potential IEPREP charter > (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Essentially accept Ken's proposal with some modifications. Still do not > like the text that Ken didn't modify so my suggested changes are > provided. Hopefully the strikeouts and additions are visible. This > proposed text brings the charter in line with the deliverables and makes > it clear that the focus is on MLPP for managed IP networks and public > networks where permissible by regulations/law. > > Stephen Perschau > > > > Carlberg>--------------------------------------------------------------- > ------------------------------ > > Internet Prioritization and Preparedness (IEPREP) Charter > *> Prioritization involves identifying communications that have authorized access to preferential treatment. > Communities of interest have viewed prioritization as one step in > facilitating response and recovery operations during emergencies/ *> disasters, or in other occasions where ordinary communications are likely to fail *> and a particular sets of authorized users (e.g., first responders, chain of command *> have a need to obtain a service that might not otherwise be available. *> These circumstance may involve communications over the Internet or private IP > networks/intranets. > *Delete> Natural disasters (e.g., hurricanes, floods, earthquakes) and those *Delete> created by man (e.g., terrorist attacks, wartime events) may occur at *Delete> any time. *> These users require > immediate access to available telecommunications resources. These > resource include not only: conventional telephone, cellular phones, and > Internet access via online terminals, IP telephones, and wireless PDAs > but also access to available network resources (e.g., bandwidth). *> Both the commercial telecommunications infrastructure and private/enterprise/military *> telecommunications infrastructures are rapidly evolving to *> Internet-based technology. The Internet community needs to consider how > its protocols can support prioritized communications in these contexts. > *> There are different ways to provide prioritization: (1) in some contexts traffic > engineering or schemas that improve the probability of *> establishing/maintaining communications during times of stress are appropriate, (2) in other contexts a > more binary approach of displacing or preempting lower priority *> communications is appropriate. > > > Carlberg>--------------------------------------------------------------- > --------------------------- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 07 18:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyzDr-0002qI-7k; Fri, 07 Jul 2006 18:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyzDq-0002pi-Bt for ieprep@ietf.org; Fri, 07 Jul 2006 18:54:54 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyzDp-00028x-20 for ieprep@ietf.org; Fri, 07 Jul 2006 18:54:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2006 15:54:52 -0700 X-IronPort-AV: i="4.06,219,1149490800"; d="scan'208"; a="327876038:sNHT51582430" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k67MsqZI029229 for ; Fri, 7 Jul 2006 15:54:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k67MsqTQ008910 for ; Fri, 7 Jul 2006 15:54:52 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:54:52 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:54:51 -0700 Message-Id: <4.3.2.7.2.20060707174632.03293c60@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jul 2006 17:54:51 -0500 To: ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jul 2006 22:54:52.0030 (UTC) FILETIME=[5B3D59E0:01C6A218] DKIM-Signature: a=rsa-sha1; q=dns; l=1018; t=1152312892; x=1153176892; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:About=20these=20recharter=20text=20suggestions...=20?; X=v=3Dcisco.com=3B=20h=3DZI2kdd+gtSE9IxNNOwwadMYqygo=3D; b=deQGOOme4LINUSmPnfqesH7CLAQ6fA8/EeqUf8inrEOqMGpvcYzXabu5mO1vOaCThS9xbWdM 1HjawngNeRUahoOFQmyYV6nZz02+W1ovnE8Vtsj+6zlRz4yzBfogos0J; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ieprep] About these recharter text suggestions... ? X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org All It appears to me that some on our list want to move away from what ieprep was orignially founded upon - disaster related communications, and towards, seemingly exclusively, military communications. I, for one, do not agree with this revolutionary shift. I believe we need to shift from a generally informative WG to a standards track WG. By this I mean to shift our focus on developing informative requirements documents that we, in ieprep, will be able to solve through standards track, or BCP, documents generated and discussed to the point of consensus, by us - in this WG. I am reading lately offerings and suggestions to make this WG all about MLPP, and I don't believe we need to make it only about MLPP, rather, we need to add MLPP functionality to what we can standardize. IEPREP can do a lot more in the area of disaster related communications, and we should not completely shift away from addressing that area, which is not fully addressed within our RFCs to date. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Jul 10 11:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxnn-0006M0-OY; Mon, 10 Jul 2006 11:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxnm-0006Lq-Fy for ieprep@ietf.org; Mon, 10 Jul 2006 11:36:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fztjg-0007wi-Q9 for ieprep@ietf.org; Mon, 10 Jul 2006 07:15:32 -0400 Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs100.ncr.disa.mil) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FztHs-0006ZS-Ec for ieprep@ietf.org; Mon, 10 Jul 2006 06:46:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] About these recharter text suggestions... ? (UNCLASSIFIED) Date: Mon, 10 Jul 2006 06:45:43 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A590C6D0E@vanualevu.disanet.disa-u.mil> in-reply-to: <4.3.2.7.2.20060707174632.03293c60@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] About these recharter text suggestions... ? (UNCLASSIFIED) Thread-Index: AcaiGGU0nNntqeIzRlSjMJZNx2NS8AB9MrQg From: "Perschau, Stephen CIV NCS NC2" To: "James M. Polk" , X-OriginalArrivalTime: 10 Jul 2006 10:45:44.0671 (UTC) FILETIME=[FF055EF0:01C6A40D] X-Spam-Score: -0.4 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE The intent of my proposed changes are to bring the text of the charter in line with the deliverables. All deliverables talked about government/military networks and had little or nothing to do with public networks. With respect to the comment on shifting from informative to standards track, couldn't agree more. Stephen=20 -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Friday, July 07, 2006 6:55 PM To: ieprep@ietf.org Subject: [Ieprep] About these recharter text suggestions... ? All It appears to me that some on our list want to move away from what ieprep was orignially founded upon - disaster related communications, and towards, seemingly exclusively, military communications. I, for one, do not agree with this revolutionary shift. I believe we need to shift from a generally informative WG to a standards track WG. By this I mean to shift our focus on developing informative requirements documents that we, in ieprep, will be able to solve through standards track, or BCP, documents generated and discussed to the point of consensus, by us - in this WG. I am reading lately offerings and suggestions to make this WG all about MLPP, and I don't believe we need to make it only about MLPP, rather, we need to add MLPP functionality to what we can standardize. IEPREP can do a lot more in the area of disaster related communications, and we should not completely shift away from addressing that area, which is not fully addressed within our RFCs to date. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jul 12 08:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0eDc-0002mO-7x; Wed, 12 Jul 2006 08:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0eDa-0002mI-J0 for ieprep@ietf.org; Wed, 12 Jul 2006 08:53:30 -0400 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0eDX-0006mU-Ae for ieprep@ietf.org; Wed, 12 Jul 2006 08:53:30 -0400 Received: from jhuapl.edu ([128.244.198.200]) by aplesnation.dom1.jhuapl.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 08:53:26 -0400 Received: from ([128.244.97.125]) by pilot.jhuapl.edu with ESMTP id 5502123.1430109; Wed, 12 Jul 2006 08:53:17 -0400 Message-ID: <44B4F17B.70105@jhuapl.edu> Date: Wed, 12 Jul 2006 08:56:27 -0400 From: "Robert G. Cole" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ieprep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2006 12:53:26.0919 (UTC) FILETIME=[2AE72170:01C6A5B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ieprep] on the ieprep charter X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Kimberly, I am not sure of the lastest revision to the charter, so will make a few general comments on various versions and discussions. I am also curious of the target date for completing the charter revision. + I agree with expanding the scope of the WG away from solely an emergency Telecomm focus to a more general emergency communications focus. I do not think a totally military focus is correct however; this is only one of several sectors the IETF needs to address. There is significant overlap in the needs for emergency services within Enterprise, Public and Military networks, that to focus on a single sector would represent a disservice to all of these communities. + I agree with the suggestion to expand beyond requirements and informational to standard track RFCs, if necessary. There are clearly gaps in the current set of standards within the scope of emergency services. That being said, I have a few specific comments: + I would shy away from the term 'Telecommunications' and use 'Communications' when refering to working group scope. Using it as an example is fine. + I generally prefer to use the term 'Precedence' in place of 'Prioritization' when refering to general capabilities and requirements. Prioritization implies (to some) a (queuing)mechanism, which may not be required in many instances. + A 'Feb 07 draft on mechanisms' is suggested. Is this to focus on transport service mechanisms and/or application level mechanisms? + Perhaps the WG should consider drafting an I-D on Application Considerations when accessing emergency transport services. I know there has been some discussion of Email/SMTP in this group. Should the charter make discussion of application considerations in scope? I think yes. I think such a document would point out some interesting interactions required between the network and the applications, e.g., access control, multiplexing, etc. Thanks, Bob _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jul 12 12:49:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hts-0004oJ-IG; Wed, 12 Jul 2006 12:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hts-0004oD-5e for ieprep@ietf.org; Wed, 12 Jul 2006 12:49:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0htq-0005sZ-RI for ieprep@ietf.org; Wed, 12 Jul 2006 12:49:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 12 Jul 2006 09:49:18 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="1837798375:sNHT5856514734" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k6CGnI4A001160; Wed, 12 Jul 2006 09:49:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6CGnFoI029734; Wed, 12 Jul 2006 09:49:15 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 09:49:15 -0700 Received: from [132.219.16.127] ([10.21.88.156]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 09:49:14 -0700 In-Reply-To: <44B4F17B.70105@jhuapl.edu> References: <44B4F17B.70105@jhuapl.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Ieprep] on the ieprep charter Date: Wed, 12 Jul 2006 12:49:07 -0400 To: "Robert G. Cole" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jul 2006 16:49:14.0724 (UTC) FILETIME=[1BA6DA40:01C6A5D3] DKIM-Signature: a=rsa-sha1; q=dns; l=2555; t=1152722958; x=1153586958; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=A0SsFnkQvEoMfBsSbPiMo/3sya6Cuoy4yFlg14eDOseB6+yu8qcOpkga/FPUYPj72QPWmrDP WDvzFYRRteIzZzMlvNUoB6lX2Ar2SgEe/3F4xYyk4hCkE4SfSgEfNM9A; Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org On Jul 12, 2006, at 8:56 AM, Robert G. Cole wrote: > + I agree with expanding the scope of the WG away from solely an > emergency Telecomm focus to a more general emergency communications > focus. I do not think a totally military focus is correct however; > this is only one of several sectors the IETF needs to address. > There is significant overlap in the needs for emergency services > within Enterprise, Public and Military networks, that to focus on a > single sector would represent a disservice to all of these > communities. yes. My observation here is that in the PSTN there is a single common set of tools used, the information elements in SS7. The implementation of these vary: some networks use preemption (my observation is that most networks I have spoken with use preemption), and some use other techniques like call queuing, trunk queuing, and alternative call routing. That argues that it is not necessary and is perhaps inappropriate to attempt to mandate that a difference in underlying implementation forces a difference in protocol. I would go a step further. At the end of the day, carriers and vendors are being asked to implement one thing or another, with enough options to cover the needs of their various countries. In the PSTN, this was done in an international body, the SS7 protocols are used world-wide, and basically those two options are used in common implementation throughout the world. This vendor sells not only to US DoD and US DHS/NCS and their contractors. Cisco sells to many service providers that offer service in multiple countries; one of such told me that their services were offered in 70 countries. Cisco also sells to NATO, which in the final analysis means that it provides tools to military networks i roughly 90 countries. Asking for this DHS/NSC vs DoD division is a microcosm of the reality that this working group needs to address. In my humble opinion, which is of course always right (but I am too humble to say so), what we really need is a single common solution that can be interoperably deployed in preemption-ok and preemption- not-ok networks in a wide variety of countries, with configuration options to deal with the differences in implementation approach. If that is in the end not the objective, then I believe the working group should not be chartered. This ultimately hurts everyone, and is not my desire, but is the only thing that would make sense in the context. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 14:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Aiz-0004Ow-Ff; Thu, 27 Jul 2006 14:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Aiy-0004Or-Tw for ieprep@ietf.org; Thu, 27 Jul 2006 14:36:44 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Aix-0002AN-NH for ieprep@ietf.org; Thu, 27 Jul 2006 14:36:44 -0400 Received: from ([128.244.96.244]) by pilot.jhuapl.edu with ESMTP id 5502123.2396550; Thu, 27 Jul 2006 14:36:19 -0400 Message-ID: <44C9089E.3050802@jhuapl.edu> Date: Thu, 27 Jul 2006 14:40:30 -0400 From: "Robert G. Cole" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker Subject: Re: [Ieprep] on the ieprep charter References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> In-Reply-To: <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Fred, So do you think the following statement is roughly true? "There is enough similarities in the needs of these broad industry segements with respect to communications requirements/needs in emergency situations that: a) Protocols can be enhanced (or in some cases developed) to handle the similarities, while b) Differences are relegated to implementations or behavior descriptions." Thanks, Bob Fred Baker wrote: > > My observation here is that in the PSTN there is a single common set of > tools used, the information elements in SS7. The implementation of > these vary: some networks use preemption (my observation is that most > networks I have spoken with use preemption), and some use other > techniques like call queuing, trunk queuing, and alternative call > routing. That argues that it is not necessary and is perhaps > inappropriate to attempt to mandate that a difference in underlying > implementation forces a difference in protocol. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 15:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BP6-0005E4-Mj; Thu, 27 Jul 2006 15:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BP5-0005BP-1G for ieprep@ietf.org; Thu, 27 Jul 2006 15:20:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BP3-0006iF-Mp for ieprep@ietf.org; Thu, 27 Jul 2006 15:20:15 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Jul 2006 12:19:51 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="436808888:sNHT2665094970" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RJJpaL026100; Thu, 27 Jul 2006 12:19:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6RJJoYr010340; Thu, 27 Jul 2006 12:19:50 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:19:50 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:19:50 -0700 In-Reply-To: <44C9089E.3050802@jhuapl.edu> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Ieprep] on the ieprep charter Date: Thu, 27 Jul 2006 12:19:49 -0700 To: "Robert G. Cole" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Jul 2006 19:19:50.0247 (UTC) FILETIME=[A1707F70:01C6B1B1] DKIM-Signature: a=rsa-sha1; q=dns; l=2237; t=1154027991; x=1154891991; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=U0wD7in9CbqngUIcaNQWuYZdNXe4mMkhRp02R4LRIlEbvf48CvGVNN4wTtkQ4pvQ7ouX4Iij ERIPvdT/vpJI1CwRgNGajOnHR7yvAIq8HJqABT+nxkeo2w6D8VfFFWzu; Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote: > "There is enough similarities in the needs of these broad industry > segements with respect to communications requirements/needs in > emergency situations that: > > a) Protocols can be enhanced (or in some cases developed) to handle > the similarities, while > > b) Differences are relegated to implementations or behavior > descriptions." Yes, that is my opinion. Just an opinion, mind you. But I should think that a common UNI and NNI signaling mechanism could be described that enabled every implementation (regardless of nation or type of network) to classify requests in an appropriate manner (routine or whatever other level might apply, and whether the customer was authorized to make the request) and then implement what needs to be done. In some networks, for some services such as VoIP and Video/IP, that will include preemption; in other networks, the same services will include trunk queuing or other approaches. For other services, such as preferring some elastic traffic over others and the transitive trust issues in delivering an email within a short stated interval, other considerations may also come into play. Note that I carefully separated that into three broad categories: UNI, NNI, and everything else. "everything else" is within a network, and I think that is the network's problem although I may have some suggestions. NNI may be able to be handled by SLAs, although one could argue that the entire discussion here is regarding edge conditions in SLAs. It is the UNI that concerns me the most, as it tends to be the place where the biggest problems occur, and where problems occur at NNIs they can be treated as a variety of aggregated UNI. It is the NNI and the UNI that are most in view in RFC 4542. One thing to consider is that the intra-network case and the NNI case are somewhat specialized( we are simply looking at IP traffic, usually in an aggregated form), while the UNI crosses a variety of types of products including SMTP servers, telephones and telephone middleware, etc ad nauseum. I think the UNI is the most interesting and important case. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 15:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bcb-0004RC-Cz; Thu, 27 Jul 2006 15:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bca-0004Qr-21 for ieprep@ietf.org; Thu, 27 Jul 2006 15:34:12 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BcY-0008MQ-PM for ieprep@ietf.org; Thu, 27 Jul 2006 15:34:12 -0400 Received: from ([128.244.96.244]) by pilot.jhuapl.edu with ESMTP id 5502123.2400938; Thu, 27 Jul 2006 15:33:39 -0400 Message-ID: <44C9160F.1060001@jhuapl.edu> Date: Thu, 27 Jul 2006 15:37:51 -0400 From: "Robert G. Cole" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker Subject: Re: [Ieprep] on the ieprep charter References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Is this something that is or should be captured within the text of the IEPREP charter, i.e., objectives for paritioning work into protocols at UNIs and NNIs and behaviors (where appropriate) within network interiors? Bob Fred Baker wrote: > On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote: > >> "There is enough similarities in the needs of these broad industry >> segements with respect to communications requirements/needs in >> emergency situations that: >> >> a) Protocols can be enhanced (or in some cases developed) to handle >> the similarities, while >> >> b) Differences are relegated to implementations or behavior >> descriptions." > > > Yes, that is my opinion. Just an opinion, mind you. But I should think > that a common UNI and NNI signaling mechanism could be described that > enabled every implementation (regardless of nation or type of network) > to classify requests in an appropriate manner (routine or whatever > other level might apply, and whether the customer was authorized to > make the request) and then implement what needs to be done. In some > networks, for some services such as VoIP and Video/IP, that will > include preemption; in other networks, the same services will include > trunk queuing or other approaches. For other services, such as > preferring some elastic traffic over others and the transitive trust > issues in delivering an email within a short stated interval, other > considerations may also come into play. > > Note that I carefully separated that into three broad categories: UNI, > NNI, and everything else. "everything else" is within a network, and I > think that is the network's problem although I may have some > suggestions. NNI may be able to be handled by SLAs, although one could > argue that the entire discussion here is regarding edge conditions in > SLAs. It is the UNI that concerns me the most, as it tends to be the > place where the biggest problems occur, and where problems occur at > NNIs they can be treated as a variety of aggregated UNI. It is the NNI > and the UNI that are most in view in RFC 4542. > > One thing to consider is that the intra-network case and the NNI case > are somewhat specialized( we are simply looking at IP traffic, usually > in an aggregated form), while the UNI crosses a variety of types of > products including SMTP servers, telephones and telephone middleware, > etc ad nauseum. I think the UNI is the most interesting and important > case. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 15:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bwf-0003xA-Mc; Thu, 27 Jul 2006 15:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bwe-0003x0-8P for ieprep@ietf.org; Thu, 27 Jul 2006 15:54:56 -0400 Received: from mail.manske.org ([65.127.251.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Bwc-0002aA-Sm for ieprep@ietf.org; Thu, 27 Jul 2006 15:54:56 -0400 Received: from mail.manske.org (localhost.manske.org [127.0.0.1]) by mail.manske.org (8.13.6/8.13.4) with ESMTP id k6RJskWD059064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Jul 2006 14:54:46 -0500 (CDT) (envelope-from hcb@layer3arts.com) Received: (from nobody@localhost) by mail.manske.org (8.13.6/8.13.4/Submit) id k6RJsk9p059063 for ieprep@ietf.org; Thu, 27 Jul 2006 14:54:46 -0500 (CDT) (envelope-from hcb@layer3arts.com) X-Authentication-Warning: mail.manske.org: nobody set sender to hcb@layer3arts.com using -f Received: from 24-182-173-239.dhcp.stls.mo.charter.com (24-182-173-239.dhcp.stls.mo.charter.com [24.182.173.239]) by webmail.layer3arts.com (IMP) with HTTP for ; Thu, 27 Jul 2006 14:54:46 -0500 Message-ID: <1154030086.44c91a06e60f0@webmail.layer3arts.com> Date: Thu, 27 Jul 2006 14:54:46 -0500 From: "Howard C. Berkowitz" To: ieprep@ietf.org Subject: Re: [Ieprep] on the ieprep charter References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 24.182.173.239 X-manske.org-MailScanner-Information: Please contact the ISP for more information X-manske.org-MailScanner: Found to be clean X-manske.org-MailScanner-From: hcb@layer3arts.com X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Quoting Fred Baker : > Note that I carefully separated that into three broad categories: > UNI, NNI, and everything else. "everything else" is within a network, > and I think that is the network's problem although I may have some > suggestions. NNI may be able to be handled by SLAs, although one > could argue that the entire discussion here is regarding edge > conditions in SLAs. It is the UNI that concerns me the most, as it > tends to be the place where the biggest problems occur, and where > problems occur at NNIs they can be treated as a variety of aggregated > UNI. It is the NNI and the UNI that are most in view in RFC 4542. As a newbie to the list, but not necessarily emergency operations, there may be additional cases. In a large disaster, it may well be that telecommunications operating facilities may be the only available buildings with adequate backup power, HVAC, and physical ruggedness to stay in service. I've encountered some very ad hoc situation where emergency responders, PSAPs, etc., temporarily operated out of telco COs and the like. It's not inconceivable, in such a circumstance, that such people may bring equipment meant for UNI, in a facility with mostly NNI and other interfaces. I'd encourage thinking about that sort of ad hoc operational requirement. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 16:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CR7-0001x7-Jb; Thu, 27 Jul 2006 16:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CR6-0001x1-EL for ieprep@ietf.org; Thu, 27 Jul 2006 16:26:24 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CR5-0001Oo-62 for ieprep@ietf.org; Thu, 27 Jul 2006 16:26:24 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 16:26:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Date: Thu, 27 Jul 2006 16:26:20 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A972C5@vanualevu.disanet.disa-u.mil> in-reply-to: <1154030086.44c91a06e60f0@webmail.layer3arts.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] on the ieprep charter (UNCLASSIFIED) Thread-Index: Acaxto3xvqP8QiIGQR+pDudFcdgY4AAAr3cg From: "Nguyen, An P CIV NCS NC2" To: "Howard C. Berkowitz" , X-OriginalArrivalTime: 27 Jul 2006 20:26:20.0943 (UTC) FILETIME=[EC1461F0:01C6B1BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Howard, Please see below. > >-----Original Message----- >From: Howard C. Berkowitz [mailto:hcb@layer3arts.com]=20 >Sent: Thursday, July 27, 2006 3:55 PM >To: ieprep@ietf.org >Subject: Re: [Ieprep] on the ieprep charter > >Quoting Fred Baker : > > >> Note that I carefully separated that into three broad categories: =20 >> UNI, NNI, and everything else. "everything else" is within a network, >> and I think that is the network's problem although I may have some =20 >> suggestions. NNI may be able to be handled by SLAs, although one =20 >> could argue that the entire discussion here is regarding edge =20 >> conditions in SLAs. It is the UNI that concerns me the most, as it =20 >> tends to be the place where the biggest problems occur, and where =20 >> problems occur at NNIs they can be treated as a variety of aggregated >> UNI. It is the NNI and the UNI that are most in view in RFC 4542. > >As a newbie to the list, but not necessarily emergency operations, there >may be >additional cases. In a large disaster, it may well be that >telecommunications >operating facilities may be the only available buildings with adequate >backup >power, HVAC, and physical ruggedness to stay in service. I've encountered >some >very ad hoc situation where emergency responders, PSAPs, etc., temporarily >operated out of telco COs and the like.=20 > >It's not inconceivable, in such a circumstance, that such people may bring >equipment meant for UNI, in a facility with mostly NNI and other >interfaces. I'd >encourage thinking about that sort of ad hoc operational requirement.=20 For ad hoc communications, do you think the IEEE 802.16x (a.k.a. WiMAX) and maybe with IEEE 802.11x (WiFi) would satisfy your requirements? If the answer is yes, then does the UNI include the WiMAX interface? Best, An _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 16:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CmF-0007Jy-N6; Thu, 27 Jul 2006 16:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CmE-0007HA-J3 for ieprep@ietf.org; Thu, 27 Jul 2006 16:48:14 -0400 Received: from mail.manske.org ([65.127.251.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CmD-0002Da-57 for ieprep@ietf.org; Thu, 27 Jul 2006 16:48:14 -0400 Received: from mail.manske.org (localhost.manske.org [127.0.0.1]) by mail.manske.org (8.13.6/8.13.4) with ESMTP id k6RKmBqQ061790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Jul 2006 15:48:11 -0500 (CDT) (envelope-from hcb@layer3arts.com) Received: (from nobody@localhost) by mail.manske.org (8.13.6/8.13.4/Submit) id k6RKmBGK061789 for ieprep@ietf.org; Thu, 27 Jul 2006 15:48:11 -0500 (CDT) (envelope-from hcb@layer3arts.com) X-Authentication-Warning: mail.manske.org: nobody set sender to hcb@layer3arts.com using -f Received: from 24-182-173-239.dhcp.stls.mo.charter.com (24-182-173-239.dhcp.stls.mo.charter.com [24.182.173.239]) by webmail.layer3arts.com (IMP) with HTTP for ; Thu, 27 Jul 2006 15:48:11 -0500 Message-ID: <1154033291.44c9268b3205e@webmail.layer3arts.com> Date: Thu, 27 Jul 2006 15:48:11 -0500 From: "Howard C. Berkowitz" To: ieprep@ietf.org Subject: RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) References: <9B4320CC9BC1D847AFFA97F25A422A59A972C5@vanualevu.disanet.disa-u.mil> In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A972C5@vanualevu.disanet.disa-u.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 24.182.173.239 X-manske.org-MailScanner-Information: Please contact the ISP for more information X-manske.org-MailScanner: Found to be clean X-manske.org-MailScanner-From: hcb@layer3arts.com X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Quoting "Nguyen, An P CIV NCS NC2" : > Howard, > > Please see below. > > > >-----Original Message----- > >From: Howard C. Berkowitz [mailto:hcb@layer3arts.com] > >Sent: Thursday, July 27, 2006 3:55 PM > >To: ieprep@ietf.org > >Subject: Re: [Ieprep] on the ieprep charter > > > >Quoting Fred Baker : > > > > > >> Note that I carefully separated that into three broad categories: > >> UNI, NNI, and everything else. "everything else" is within a network, > > >> and I think that is the network's problem although I may have some > >> suggestions. NNI may be able to be handled by SLAs, although one > >> could argue that the entire discussion here is regarding edge > >> conditions in SLAs. It is the UNI that concerns me the most, as it > >> tends to be the place where the biggest problems occur, and where > >> problems occur at NNIs they can be treated as a variety of aggregated > > >> UNI. It is the NNI and the UNI that are most in view in RFC 4542. > > > >As a newbie to the list, but not necessarily emergency operations, > there >may be > >additional cases. In a large disaster, it may well be that > >telecommunications > >operating facilities may be the only available buildings with adequate > >backup > >power, HVAC, and physical ruggedness to stay in service. I've > encountered >some > >very ad hoc situation where emergency responders, PSAPs, etc., > temporarily > >operated out of telco COs and the like. > > > >It's not inconceivable, in such a circumstance, that such people may > bring > >equipment meant for UNI, in a facility with mostly NNI and other > >interfaces. I'd > >encourage thinking about that sort of ad hoc operational requirement. > > For ad hoc communications, do you think the IEEE 802.16x (a.k.a. WiMAX) > and maybe with IEEE 802.11x (WiFi) would satisfy your requirements? If > the answer is yes, then does the UNI include the WiMAX interface? > That's a good question. My immediate thought is that potentially either would work, probably more likely 802.11 if someone is moving temporary equipment into carrier facilities. If the equipment speaks VoIP, and can use it as needed to interface to tactical voice and data radio, an 802.3 interface puts us in reasonable shape. That should cover many requirements. My concern, and I agree some of this is hypothetical, is that some EOCs expect PDH or ATM links to their switch. We'd need some survey data to find out how frequently this would arise, and whether transportable gateways need to be available. There's a reverse side of this to consider, although it won't have as many interfacing issues since the equipment is more self-contained. Consider the situation where the telco offices are flooded, but a local hospital is on high ground, has adequate generators, etc. It's a plausible place for helicopter delivery of emergency radio repeaters, cellular base stations, etc. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 17:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D3Q-0004Ny-OI; Thu, 27 Jul 2006 17:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D3P-0004Nr-Dg for ieprep@ietf.org; Thu, 27 Jul 2006 17:05:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6D3M-0008ED-Uo for ieprep@ietf.org; Thu, 27 Jul 2006 17:05:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Jul 2006 14:05:54 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="331958320:sNHT28558316" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RL5sY9021982; Thu, 27 Jul 2006 14:05:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6RL5qYr026152; Thu, 27 Jul 2006 14:05:52 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 14:05:49 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 14:05:48 -0700 In-Reply-To: <44C9160F.1060001@jhuapl.edu> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Ieprep] on the ieprep charter Date: Thu, 27 Jul 2006 14:05:46 -0700 To: "Robert G. Cole" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Jul 2006 21:05:48.0801 (UTC) FILETIME=[6F6ED710:01C6B1C0] DKIM-Signature: a=rsa-sha1; q=dns; l=4466; t=1154034354; x=1154898354; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=nNj6UdUQ7R6UBFLVOowOCVfre4mZAsa4AO1NcjunmegCw/T61wiPr+svmmn72A9T331WWC1b ZFwR6VDEWO6W9pgUb0R+FS+M1Zu+R35tnHclpTG7KSRHZ8ub8jEx88x5; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org I think it is possible to over-constrain the working group outputs, and so would not go into that level of detail in the charter. For example, we might decide in the course of working the issue that the division isn't worthwhile, and then find that we have to change the charter to ignore it. The important thing to me is that the charter should describe us providing a signaling solution that is - applicable to a variety of implementations, including preemptive and non-preemptive, - appropriate throughout the Internet, not just in the subset that happens to be relevant to the US Government, whether civil or military, and - addresses both inter-provider and provider/customer connectivity. I think it should also very clearly require both application layer CAC (eg, "who are you" and "what are you authorized to do" for some appropriate set of definitions) and network layer CAC (eg, at this instant, does the network have resources to address your requirements, and if not what is it going to do about that). Since the two questions are very different, there should be no assumption that only one needs to be solved or that one solution solves both. What the charter should, perhaps, address, is the status of multicast in this. We all agree we need unicast solutions. RSVP assumes that multicast is also a requirement, while NSIS presumes that it can be summarily set aside. In civilian networks where multicast is not widely deployed as a service, the point may be moot. I am told that in your organization and others in coalition with it, there are places where multicast is the predominant traffic type, however. So we have to decide whether we need to address that. On Jul 27, 2006, at 12:37 PM, Robert G. Cole wrote: > Is this something that is or should be captured within the text of > the IEPREP charter, i.e., objectives for paritioning work into > protocols at UNIs and NNIs and behaviors (where appropriate) within > network interiors? > > Bob > > Fred Baker wrote: >> On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote: >>> "There is enough similarities in the needs of these broad >>> industry segements with respect to communications requirements/ >>> needs in emergency situations that: >>> >>> a) Protocols can be enhanced (or in some cases developed) to >>> handle the similarities, while >>> >>> b) Differences are relegated to implementations or behavior >>> descriptions." >> Yes, that is my opinion. Just an opinion, mind you. But I should >> think that a common UNI and NNI signaling mechanism could be >> described that enabled every implementation (regardless of nation >> or type of network) to classify requests in an appropriate >> manner (routine or whatever other level might apply, and whether >> the customer was authorized to make the request) and then >> implement what needs to be done. In some networks, for some >> services such as VoIP and Video/IP, that will include preemption; >> in other networks, the same services will include trunk queuing >> or other approaches. For other services, such as preferring some >> elastic traffic over others and the transitive trust issues in >> delivering an email within a short stated interval, other >> considerations may also come into play. >> >> Note that I carefully separated that into three broad categories: >> UNI, NNI, and everything else. "everything else" is within a >> network, and I think that is the network's problem although I may >> have some suggestions. NNI may be able to be handled by SLAs, >> although one could argue that the entire discussion here is >> regarding edge conditions in SLAs. It is the UNI that concerns me >> the most, as it tends to be the place where the biggest problems >> occur, and where problems occur at NNIs they can be treated as a >> variety of aggregated UNI. It is the NNI and the UNI that are >> most in view in RFC 4542. >> >> One thing to consider is that the intra-network case and the NNI >> case are somewhat specialized( we are simply looking at IP >> traffic, usually in an aggregated form), while the UNI crosses a >> variety of types of products including SMTP servers, telephones >> and telephone middleware, etc ad nauseum. I think the UNI is the >> most interesting and important case. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 17:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DOT-0000aU-F5; Thu, 27 Jul 2006 17:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DOR-0000aN-QE for ieprep@ietf.org; Thu, 27 Jul 2006 17:27:43 -0400 Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DOO-0003lE-Sp for ieprep@ietf.org; Thu, 27 Jul 2006 17:27:43 -0400 Received: from north-latitude.nps.navy.mil ([131.120.179.249] RDNS failed) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 14:28:22 -0700 Subject: RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) From: Rex Buddenberg To: "Howard C. Berkowitz" In-Reply-To: <1154033291.44c9268b3205e@webmail.layer3arts.com> References: <9B4320CC9BC1D847AFFA97F25A422A59A972C5@vanualevu.disanet.disa-u.mil> <1154033291.44c9268b3205e@webmail.layer3arts.com> Content-Type: text/plain Date: Thu, 27 Jul 2006 14:27:27 -0700 Message-Id: <1154035648.5427.318.camel@north-latitude.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 21:28:22.0831 (UTC) FILETIME=[967F6BF0:01C6B1C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org On Thu, 2006-07-27 at 15:48 -0500, Howard C. Berkowitz wrote: > Quoting "Nguyen, An P CIV NCS NC2" : > > > > Howard, > > [deletia] > > > > For ad hoc communications, do you think the IEEE 802.16x (a.k.a. WiMAX) > > and maybe with IEEE 802.11x (WiFi) would satisfy your requirements? If > > the answer is yes, then does the UNI include the WiMAX interface? > > > That's a good question. My immediate thought is that potentially either would > work, probably more likely 802.11 if someone is moving temporary equipment into > carrier facilities. If the equipment speaks VoIP, and can use it as needed to > interface to tactical voice and data radio, an 802.3 interface puts us in > reasonable shape. That should cover many requirements. Howard, WiMAX payloads are wrapped in ethernet frames just like WiFi, DOCSIS, ... and ethernet itself. In 802 SAP terms, all use the 802.2 LLC. (And so will 802.20 and 802.22 if they ever see light of day, which is looking more and more problematic). The 802.16 gear we have in lab -- 2-3 generations worth now -- all has ethernet interfaces to the next network over. Both BS and SS. So my students simply see an RJ-45 plug ... and it works the same way their cable modem at home works. Bridging is so ubiquitous that nobody notices it anymore. > > My concern, and I agree some of this is hypothetical, is that some EOCs expect > PDH or ATM links to their switch. The 802.16 literature says 'does ATM' but I'm not entirely sure what that means. And because the military infrastructure has so little of it ... and definitely NOT on the battlefield, I've never worried farther. > Consider the > situation where the telco offices are flooded, but a local hospital is on high > ground, has adequate generators, etc. It's a plausible place for helicopter > delivery of emergency radio repeaters, cellular base stations, etc. This is the situation we found when a colleague of mine looted my lab, grabbed a bunch of students and headed to New Orleans last fall. Ended up setting up in Waveland, Ms where there was essentially no infrastructure left -- no wired phone, no cellphone, and no electricity. The laydown consisted of: - an 802.16 backbone - an 802.11 access network at each .16 node (lit up schools, fire and police stations, a hospital and a couple other sites). J-random laptops could connect up. - concentrate the .16 stuff to a router that has a satcom link to undamaged internet (DoD-speak is 'reachback'). The kit the guys took had generators and assorted camping gear. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Thu Jul 27 23:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6J0S-0004lT-9N; Thu, 27 Jul 2006 23:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6J0R-0004jo-Qn for ieprep@ietf.org; Thu, 27 Jul 2006 23:27:19 -0400 Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6J0Q-0003gm-HI for ieprep@ietf.org; Thu, 27 Jul 2006 23:27:19 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G6J0K-0004yj-74; Fri, 28 Jul 2006 04:27:14 +0100 In-Reply-To: References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] on the ieprep charter Date: Thu, 27 Jul 2006 23:27:06 -0400 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Robert G. Cole" , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org > What the charter should, perhaps, address, is the status of > multicast in this. We all agree we need unicast solutions. RSVP > assumes that multicast is also a requirement, while NSIS presumes > that it can be summarily set aside. In civilian networks where > multicast is not widely deployed as a service, the point may be > moot. I am told that in your organization and others in coalition > with it, there are places where multicast is the predominant > traffic type, however. So we have to decide whether we need to > address that. I'll chime up and say we *definitely* need to address multicast. its fundamental in the context of efficiently supporting push-to-talk applications as one pushes IP further into the infrastructure of Land Mobile Radio. and the subject becomes more of a headache since the establishment of talk groups are not based on explicitly signaled CAC -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 28 03:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MqL-0001mh-5O; Fri, 28 Jul 2006 03:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MqJ-0001fN-G0 for ieprep@ietf.org; Fri, 28 Jul 2006 03:33:07 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6MqH-0005xk-UO for ieprep@ietf.org; Fri, 28 Jul 2006 03:33:07 -0400 Received: (qmail invoked by alias); 28 Jul 2006 07:33:01 -0000 Received: from ip-80-226-183-0.vodafone-net.de (EHLO [10.226.165.1]) [80.226.183.0] by mail.gmx.net (mp015) with SMTP; 28 Jul 2006 09:33:01 +0200 X-Authenticated: #29516787 Message-ID: <44C9BDAD.7020004@gmx.net> Date: Fri, 28 Jul 2006 09:33:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ieprep@ietf.org References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ieprep] Question about the IEPREP Recharting Proposal X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Hi all, I haven't follwed the IEPREP working group too closely in the past. This week I read through all the documents and I also went through the rechartering proposal. As an "outsider" I was not quite sure what exactly you would like todo? (i.e., what should the new documents cover that is not addressed in previous docs). Do you have some documents that could tell me what you guys plan todo? How do these documents relate to the new charter items? Sorry, if I appear a little bit lost... Ciao Hannes _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 28 12:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V18-0002ex-K1; Fri, 28 Jul 2006 12:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V17-0002es-Dv for ieprep@ietf.org; Fri, 28 Jul 2006 12:16:49 -0400 Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6V15-0004CC-JP for ieprep@ietf.org; Fri, 28 Jul 2006 12:16:49 -0400 Received: from north-latitude.nps.navy.mil ([131.120.179.249] RDNS failed) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:17:34 -0700 Subject: Re: [Ieprep] on the ieprep charter From: Rex Buddenberg To: ken carlberg In-Reply-To: <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> Content-Type: text/plain Date: Fri, 28 Jul 2006 09:16:39 -0700 Message-Id: <1154103399.5427.366.camel@north-latitude.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 16:17:34.0178 (UTC) FILETIME=[55728C20:01C6B261] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Robert G. Cole" , Fred Baker , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Ken, You're correct on multicast. Reinforce: - demand side. A great deal of data in both military and emergency services is multicast in nature. Much higher proportion than in commercial world. And as soon as you factor in high availability engineering, everything becomes multicast -- you send data >1 place so a lucky hit on target A doesn't take all the data. - supply side. Increasingly we can look at the radio-WANs as interior network segments. Platforms have LANs in them and the radio-WAN has no end systems on it -- they're all on the LAN, other side of the router. This is most obvious in the surface navy today, but it's a trend. Both LANs and the fixed internet are or can easily be provisioned at G and 10G capacities (even in US DoD!). But as soon as you hit the radio-WAN in the middle, you suffer ~4 order of magnitude capacity hit -- best numbers are in 10s of M. Multicast is the only offset to that capacity hit. PTT radios are just one instantiation of this observation. On Thu, 2006-07-27 at 23:27 -0400, ken carlberg wrote: > > What the charter should, perhaps, address, is the status of > > multicast in this. We all agree we need unicast solutions. RSVP > > assumes that multicast is also a requirement, while NSIS presumes > > that it can be summarily set aside. In civilian networks where > > multicast is not widely deployed as a service, the point may be > > moot. I am told that in your organization and others in coalition > > with it, there are places where multicast is the predominant > > traffic type, however. So we have to decide whether we need to > > address that. > > I'll chime up and say we *definitely* need to address multicast. its > fundamental in the context of efficiently supporting push-to-talk > applications as one pushes IP further into the infrastructure of Land > Mobile Radio. and the subject becomes more of a headache since the > establishment of talk groups are not based on explicitly signaled CAC > > -ken > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 28 14:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XIa-0002tp-Ky; Fri, 28 Jul 2006 14:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XIY-0002tT-L0 for ieprep@ietf.org; Fri, 28 Jul 2006 14:42:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XIW-0007IO-7X for ieprep@ietf.org; Fri, 28 Jul 2006 14:42:58 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2006 11:42:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SIgt6t010139; Fri, 28 Jul 2006 11:42:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6SIgtJi003279; Fri, 28 Jul 2006 11:42:55 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 11:42:55 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 11:42:54 -0700 In-Reply-To: <1154103399.5427.366.camel@north-latitude.nps.navy.mil> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> <1154103399.5427.366.camel@north-latitude.nps.navy.mil> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Ieprep] on the ieprep charter Date: Fri, 28 Jul 2006 11:42:53 -0700 To: ken carlberg X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Jul 2006 18:42:54.0908 (UTC) FILETIME=[A36857C0:01C6B275] DKIM-Signature: a=rsa-sha1; q=dns; l=3120; t=1154112175; x=1154976175; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=XyfU1m1+J7yDS2h0MWCdAyFtC/wr8ZnJYSNoOyzXH+/iJjnWgdhlMKc/McRWEHoO6iIKNPHu oHj2gqh6e8Un60wvigNTCzDA6pssNyKYU9YdwpeSFZzavdkuXGNxy7NA; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Rex Buddenberg , Robert Cole , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org In the general case, I would expect push-to-talk to be handled by provisioning. I'm not certain that the capability is of an "emergency" nature. In civilian networks, it is commonly used on virtual trading floors and as a walkie-talkie replacement. I can't say I know for certain how it is used in military networks (they haven't told me), but I would expect that it permits communication among a physically distributed group of people that operate as a team, such as command/control operations. In civilian networks, the way it generally works is by ensuring (either by provisioning of bandwidth or by placing traffic into an appropriate class) that there is bandwidth available to the application at the time it needs it, and is generally a low capacity channel. On Jul 28, 2006, at 9:16 AM, Rex Buddenberg wrote: > Ken, > > You're correct on multicast. Reinforce: > > - demand side. A great deal of data in both military and emergency > services is multicast in nature. Much higher proportion than in > commercial world. And as soon as you factor in high availability > engineering, everything becomes multicast -- you send data >1 place > so a > lucky hit on target A doesn't take all the data. > > - supply side. Increasingly we can look at the radio-WANs as interior > network segments. Platforms have LANs in them and the radio-WAN > has no > end systems on it -- they're all on the LAN, other side of the router. > This is most obvious in the surface navy today, but it's a trend. > Both > LANs and the fixed internet are or can easily be provisioned at G and > 10G capacities (even in US DoD!). But as soon as you hit the radio- > WAN > in the middle, you suffer ~4 order of magnitude capacity hit -- best > numbers are in 10s of M. Multicast is the only offset to that > capacity > hit. > > PTT radios are just one instantiation of this observation. > > > On Thu, 2006-07-27 at 23:27 -0400, ken carlberg wrote: >>> What the charter should, perhaps, address, is the status of >>> multicast in this. We all agree we need unicast solutions. RSVP >>> assumes that multicast is also a requirement, while NSIS presumes >>> that it can be summarily set aside. In civilian networks where >>> multicast is not widely deployed as a service, the point may be >>> moot. I am told that in your organization and others in coalition >>> with it, there are places where multicast is the predominant >>> traffic type, however. So we have to decide whether we need to >>> address that. >> >> I'll chime up and say we *definitely* need to address multicast. its >> fundamental in the context of efficiently supporting push-to-talk >> applications as one pushes IP further into the infrastructure of Land >> Mobile Radio. and the subject becomes more of a headache since the >> establishment of talk groups are not based on explicitly signaled CAC >> >> -ken >> >> >> _______________________________________________ >> Ieprep mailing list >> Ieprep@ietf.org >> https://www1.ietf.org/mailman/listinfo/ieprep > -- > b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 28 15:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XgN-0005QY-Vb; Fri, 28 Jul 2006 15:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XgM-0005QT-QI for ieprep@ietf.org; Fri, 28 Jul 2006 15:07:34 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XgG-00013v-Ln for ieprep@ietf.org; Fri, 28 Jul 2006 15:07:34 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6SJ7Q8l024950; Fri, 28 Jul 2006 15:07:26 -0400 (EDT) In-Reply-To: <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com> Subject: Re: [Ieprep] on the ieprep charter To: Fred Baker X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 28 Jul 2006 15:07:23 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/28/2006 03:06:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Rex Buddenberg , Robert Cole , ieprep@ietf.org, ken carlberg X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- (Sorry all- I've been told I am not allowed to delete this) Fred, My understanding is that, on the civilian side, "Push to Talk" is quite widely used by "first responders", and by the groups responsible for repairing/maintaining "the infrastructure" (e.g., telephone networks, power grids, water and sewage systems, highways, oil pipelines) . These are considered part of the "National Security/Emergency Preparedness" functionality. At least one of the deployed services uses 5 levels of priority. Janet Fred Baker wrote on 07/28/2006 02:42:53 PM: > In the general case, I would expect push-to-talk to be handled by > provisioning. I'm not certain that the capability is of an > "emergency" nature. In civilian networks, it is commonly used on > virtual trading floors and as a walkie-talkie replacement. I can't > say I know for certain how it is used in military networks (they > haven't told me), but I would expect that it permits communication > among a physically distributed group of people that operate as a > team, such as command/control operations. In civilian networks, the > way it generally works is by ensuring (either by provisioning of > bandwidth or by placing traffic into an appropriate class) that there > is bandwidth available to the application at the time it needs it, > and is generally a low capacity channel. > > On Jul 28, 2006, at 9:16 AM, Rex Buddenberg wrote: > > > Ken, > > > > You're correct on multicast. Reinforce: > > > > - demand side. A great deal of data in both military and emergency > > services is multicast in nature. Much higher proportion than in > > commercial world. And as soon as you factor in high availability > > engineering, everything becomes multicast -- you send data >1 place > > so a > > lucky hit on target A doesn't take all the data. > > > > - supply side. Increasingly we can look at the radio-WANs as interior > > network segments. Platforms have LANs in them and the radio-WAN > > has no > > end systems on it -- they're all on the LAN, other side of the router. > > This is most obvious in the surface navy today, but it's a trend. > > Both > > LANs and the fixed internet are or can easily be provisioned at G and > > 10G capacities (even in US DoD!). But as soon as you hit the radio- > > WAN > > in the middle, you suffer ~4 order of magnitude capacity hit -- best > > numbers are in 10s of M. Multicast is the only offset to that > > capacity > > hit. > > > > PTT radios are just one instantiation of this observation. > > > > > > On Thu, 2006-07-27 at 23:27 -0400, ken carlberg wrote: > >>> What the charter should, perhaps, address, is the status of > >>> multicast in this. We all agree we need unicast solutions. RSVP > >>> assumes that multicast is also a requirement, while NSIS presumes > >>> that it can be summarily set aside. In civilian networks where > >>> multicast is not widely deployed as a service, the point may be > >>> moot. I am told that in your organization and others in coalition > >>> with it, there are places where multicast is the predominant > >>> traffic type, however. So we have to decide whether we need to > >>> address that. > >> > >> I'll chime up and say we *definitely* need to address multicast. its > >> fundamental in the context of efficiently supporting push-to-talk > >> applications as one pushes IP further into the infrastructure of Land > >> Mobile Radio. and the subject becomes more of a headache since the > >> establishment of talk groups are not based on explicitly signaled CAC > >> > >> -ken > >> > >> > >> _______________________________________________ > >> Ieprep mailing list > >> Ieprep@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ieprep > > -- > > b > > _______________________________________________ > 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-bounces@ietf.org Fri Jul 28 15:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YOC-0008Mt-TS; Fri, 28 Jul 2006 15:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YOB-0008L1-EB for ieprep@ietf.org; Fri, 28 Jul 2006 15:52:51 -0400 Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YOA-0006hL-20 for ieprep@ietf.org; Fri, 28 Jul 2006 15:52:51 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from ) id 1G6YO9-0000Lp-Vf; Fri, 28 Jul 2006 20:52:50 +0100 In-Reply-To: <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> <4594B807-4EDB-45A4-B2FB-0DCD30E7C3FC@g11.org.uk> <1154103399.5427.366.camel@north-latitude.nps.navy.mil> <042EB3AC-C5A9-463E-B2B6-308231411ED9@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <932AEBC1-2418-40B7-8AB7-5E3C83628846@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] on the ieprep charter Date: Fri, 28 Jul 2006 15:52:40 -0400 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Rex Buddenberg , Robert Cole , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Fred, > In the general case, I would expect push-to-talk to be handled by > provisioning. I'm not certain that the capability is of an > "emergency" nature. In civilian networks, it is commonly used on > virtual trading floors and as a walkie-talkie replacement. I can't > say I know for certain how it is used in military networks (they > haven't told me), but I would expect that it permits communication > among a physically distributed group of people that operate as a > team, such as command/control operations. In civilian networks, the > way it generally works is by ensuring (either by provisioning of > bandwidth or by placing traffic into an appropriate class) that > there is bandwidth available to the application at the time it > needs it, and is generally a low capacity channel. a good read on things, though the headache arises in the details. Today, provisioning in LMR systems used by first responders (police, firemen, EMS, etc.) is accomplished by man-in-the-loop dispatchers that assign channels per talkgroup (analogous to per multicast group). and what is known as "radio discipline" (by end users) is primarily used to control contention on the channel. failing that, the dispatcher manages the group and can assign more talkgroups/ channels, though these are limited. and as Janet mentioned, prioritization in LMR (layer 2) packets has recently been added tot he mix. Project 16a of APCO defined a set of 5 priorities, and Project 25 defines 7 levels. one moral in that story is not to be fixated on the number of levels....they may change. my understanding is that the number of towers involved in a talkgroup generally range from 0 (direct communication between end users) to 4, with a gausian decay after that. today, these towers don't have IP embedded within them, but that will come in time. outside of this, there are also remote observer participants that receive the communications from remote geographic regions. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jul 28 18:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ais-0008Gi-0F; Fri, 28 Jul 2006 18:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aiq-00089P-9q for ieprep@ietf.org; Fri, 28 Jul 2006 18:22:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Ylc-0000mc-EY for ieprep@ietf.org; Fri, 28 Jul 2006 16:17:04 -0400 Received: from athena.hosts.co.uk ([212.84.175.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6YV9-0004DY-AW for ieprep@ietf.org; Fri, 28 Jul 2006 16:00:05 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1G6YV6-0001So-63; Fri, 28 Jul 2006 21:00:00 +0100 In-Reply-To: <44C9BDAD.7020004@gmx.net> References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> <44C9BDAD.7020004@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] Question about the IEPREP Recharting Proposal Date: Fri, 28 Jul 2006 15:59:50 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Hannes, in a nutshell, the intent of the re-charter was to go beyond requirements and in some form consider solutions that do not fall within the charter of other working groups. I believe that there are some other interested parties that have been working on drafts that go beyond previous work done by the group, but that they are awaiting the results of the proposed rechartering discussions. However, others should probably speak up on that matter. -ken On Jul 28, 2006, at 3:33 AM, Hannes Tschofenig wrote: > Hi all, > > I haven't follwed the IEPREP working group too closely in the past. > This week I read through all the documents and I also went through > the rechartering proposal. > > As an "outsider" I was not quite sure what exactly you would like > todo? (i.e., what should the new documents cover that is not > addressed in previous docs). > Do you have some documents that could tell me what you guys plan todo? > How do these documents relate to the new charter items? > > Sorry, if I appear a little bit lost... > > Ciao > Hannes > > _______________________________________________ > 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-bounces@ietf.org Sat Jul 29 15:40:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6uft-0007W9-KF; Sat, 29 Jul 2006 15:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ufr-0007W4-Vf for ieprep@ietf.org; Sat, 29 Jul 2006 15:40:35 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6ufq-0003t0-IS for ieprep@ietf.org; Sat, 29 Jul 2006 15:40:35 -0400 Received: (qmail invoked by alias); 29 Jul 2006 19:40:33 -0000 Received: from p54987724.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.119.36] by mail.gmx.net (mp042) with SMTP; 29 Jul 2006 21:40:33 +0200 X-Authenticated: #29516787 Message-ID: <44CBB9BD.5040104@gmx.net> Date: Sat, 29 Jul 2006 21:40:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ken carlberg Subject: Re: [Ieprep] Question about the IEPREP Recharting Proposal References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <44C9160F.1060001@jhuapl.edu> <44C9BDAD.7020004@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Rechartering is a lot simpler if first document versions are available and the group can look at them in order to decide whether it makes sense to extend the charter in a particular way. Ciao Hannes ken carlberg wrote: > Hannes, > > in a nutshell, the intent of the re-charter was to go beyond > requirements and in some form consider solutions that do not fall > within the charter of other working groups. > > I believe that there are some other interested parties that have been > working on drafts that go beyond previous work done by the group, but > that they are awaiting the results of the proposed rechartering > discussions. However, others should probably speak up on that matter. > > -ken > > On Jul 28, 2006, at 3:33 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> I haven't follwed the IEPREP working group too closely in the past. >> This week I read through all the documents and I also went through >> the rechartering proposal. >> >> As an "outsider" I was not quite sure what exactly you would like >> todo? (i.e., what should the new documents cover that is not >> addressed in previous docs). >> Do you have some documents that could tell me what you guys plan todo? >> How do these documents relate to the new charter items? >> >> Sorry, if I appear a little bit lost... >> >> Ciao >> Hannes >> >> _______________________________________________ >> 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-bounces@ietf.org Mon Jul 31 13:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7bxu-0004R9-Eh; Mon, 31 Jul 2006 13:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7bxt-0004R0-HA for ieprep@ietf.org; Mon, 31 Jul 2006 13:54:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7bxs-00013f-7A for ieprep@ietf.org; Mon, 31 Jul 2006 13:54:05 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2006 10:54:02 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="332847839:sNHT25100600" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VHs37S018564 for ; Mon, 31 Jul 2006 10:54:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6VHs3Yr011237 for ; Mon, 31 Jul 2006 10:54:03 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 10:54:02 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 10:54:02 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <72EC7AFD-0960-4EF0-B628-B8972D80C927@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ieprep@ietf.org From: Fred Baker Date: Mon, 31 Jul 2006 10:54:01 -0700 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Jul 2006 17:54:02.0921 (UTC) FILETIME=[4F0BE190:01C6B4CA] DKIM-Signature: a=rsa-sha1; q=dns; l=448; t=1154368443; x=1155232443; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Preferential=20Services; X=v=3Dcisco.com=3B=20h=3D42B0OO36rHG3huX5QzrQY3Rzkq8=3D; b=c36xQEDyGl1b1liKm+iYvcrcq5tPwb1KlrCMTBvAVmsJparsAV9jqLNZDIHGV8ZtYrz2VcHx VsTMLPri/m7TdvXHeJozNjUg54E9sIjVF/DoKpBXd9h+3gI60rCc7CK8; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ieprep] Preferential Services X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org You know, I think one thing that trips this group up is in the title. The issue this Working Group is thinking about is not so much "Emergency use of the Internet", which is often about deploying a new network when the usual one has been smashed by a hurricane or an airplane crash, but "Precedence-related Services in the Internet". Would it make sense, in this recharter, to call it "Preferential Services" or some such thing? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Jul 31 14:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cYq-0005ij-5E; Mon, 31 Jul 2006 14:32:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cYo-0005id-Aj for ieprep@ietf.org; Mon, 31 Jul 2006 14:32:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cYo-0004SS-8f for ieprep@ietf.org; Mon, 31 Jul 2006 14:32:14 -0400 Received: from mail.manske.org ([65.127.251.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7cYm-0005uW-BH for ieprep@ietf.org; Mon, 31 Jul 2006 14:32:14 -0400 Received: from mail.manske.org (localhost.manske.org [127.0.0.1]) by mail.manske.org (8.13.6/8.13.4) with ESMTP id k6VIW0Gj018308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Jul 2006 13:32:00 -0500 (CDT) (envelope-from hcb@layer3arts.com) Received: (from nobody@localhost) by mail.manske.org (8.13.6/8.13.4/Submit) id k6VIW0XV018307 for ieprep@ietf.org; Mon, 31 Jul 2006 13:32:00 -0500 (CDT) (envelope-from hcb@layer3arts.com) X-Authentication-Warning: mail.manske.org: nobody set sender to hcb@layer3arts.com using -f Received: from 24-182-173-239.dhcp.stls.mo.charter.com (24-182-173-239.dhcp.stls.mo.charter.com [24.182.173.239]) by webmail.layer3arts.com (IMP) with HTTP for ; Mon, 31 Jul 2006 13:32:00 -0500 Message-ID: <1154370720.44ce4ca0ba14e@webmail.layer3arts.com> Date: Mon, 31 Jul 2006 13:32:00 -0500 From: "Howard C. Berkowitz" To: ieprep@ietf.org Subject: Re: [Ieprep] Preferential Services References: <72EC7AFD-0960-4EF0-B628-B8972D80C927@cisco.com> In-Reply-To: <72EC7AFD-0960-4EF0-B628-B8972D80C927@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 24.182.173.239 X-manske.org-MailScanner-Information: Please contact the ISP for more information X-manske.org-MailScanner: Found to be clean X-manske.org-MailScanner-From: hcb@layer3arts.com X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Quoting Fred Baker : > You know, I think one thing that trips this group up is in the title. > The issue this Working Group is thinking about is not so much > "Emergency use of the Internet", which is often about deploying a new > network when the usual one has been smashed by a hurricane or an > airplane crash, but "Precedence-related Services in the Internet". > > Would it make sense, in this recharter, to call it "Preferential > Services" or some such thing? Maybe. My first reaction to "Preferential Services" made me think of in-process communications. I would argue against Precedence-Related, because the problem is really both establishing and continuing preferential services. A significant part of that is going to be ad-hoc provisioning and failure circumvention, as distinct from precedence. It's not quite MANET with respect to mobility, but the ad-hoc-ness is a necessary part of the scope. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Jul 31 14:59:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cyn-00053a-EH; Mon, 31 Jul 2006 14:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cym-00053V-28 for ieprep@ietf.org; Mon, 31 Jul 2006 14:59:04 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cyk-0008L7-OU for ieprep@ietf.org; Mon, 31 Jul 2006 14:59:04 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6VIwkiN008283; Mon, 31 Jul 2006 13:59:01 -0500 (CDT) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.6]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 31 Jul 2006 13:58:46 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Ieprep] Preferential Services Date: Mon, 31 Jul 2006 13:58:43 -0500 Message-ID: <7A5EF92F6D86BD419418FFBD69E882B60157AE51@ILEXC1U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] Preferential Services Thread-Index: Aca0yl4v1k2kmrvKSqCrX2ZLSJS2KgACFbsg From: "GOLDMAN, STUART O \(STUART\)" To: "Fred Baker" , X-OriginalArrivalTime: 31 Jul 2006 18:58:46.0159 (UTC) FILETIME=[59A2F9F0:01C6B4D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Fred, When people think of "preferential services" often they may think of silver, gold, & platinum services such as the airlines have where you get preferential service by paying more, or doing more business with the service provider. Do we need a term that better reminds us of the more unique nature of the "IEPREP" users in that they provide a service during an emergency? Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Monday, July 31, 2006 10:54 AM To: ieprep@ietf.org Subject: [Ieprep] Preferential Services You know, I think one thing that trips this group up is in the title. =20 The issue this Working Group is thinking about is not so much =20 "Emergency use of the Internet", which is often about deploying a new =20 network when the usual one has been smashed by a hurricane or an =20 airplane crash, but "Precedence-related Services in the Internet". Would it make sense, in this recharter, to call it "Preferential =20 Services" or some such thing? _______________________________________________ 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-bounces@ietf.org Mon Jul 31 15:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7d49-0007ER-Vp; Mon, 31 Jul 2006 15:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7d48-0007EG-WF for ieprep@ietf.org; Mon, 31 Jul 2006 15:04:37 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7d47-00016l-LT for ieprep@ietf.org; Mon, 31 Jul 2006 15:04:36 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=UngqawtcMfmizWHXDrPBcQxojGnMxFOYrCghJUeURezqcRNhkA8oHBHNoYoo4Up3; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G7d46-00058t-Mm; Mon, 31 Jul 2006 15:04:34 -0400 Received: from 20.132.16.4 by webmail.pas.earthlink.net with HTTP; Mon, 31 Jul 2006 15:04:33 -0400 Message-ID: <20031409.1154372674520.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Mon, 31 Jul 2006 15:04:33 -0400 (EDT) From: Janet Gunn To: "GOLDMAN,STUART O (STUART)" , Fred Baker , ieprep@ietf.org Subject: RE: [Ieprep] Preferential Services Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: ee238991c8bb1512372ac5f331c56529fbc880f602d3f026b4bcd36e3167c90a34e22bb573adfea6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Janet Gunn List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org I have a similar reaction to Stu's. "Preferential Services" somehow loses the "it is for your own good", or "for the greater good" connotation that goes with "Emergency Preparedness". Janet -----Original Message----- >From: "GOLDMAN, STUART O (STUART)" >Sent: Jul 31, 2006 2:58 PM >To: Fred Baker , ieprep@ietf.org >Subject: RE: [Ieprep] Preferential Services > >Fred, > >When people think of "preferential services" often they may think of >silver, gold, & platinum services such as the airlines have where you >get preferential service by paying more, or doing more business with the >service provider. Do we need a term that better reminds us of the more >unique nature of the "IEPREP" users in that they provide a service >during an emergency? > >Stuart Goldman >Lucent Technologies >sgoldman@lucent.com >602 493 8438 > >-----Original Message----- >From: Fred Baker [mailto:fred@cisco.com] >Sent: Monday, July 31, 2006 10:54 AM >To: ieprep@ietf.org >Subject: [Ieprep] Preferential Services > >You know, I think one thing that trips this group up is in the title. >The issue this Working Group is thinking about is not so much >"Emergency use of the Internet", which is often about deploying a new >network when the usual one has been smashed by a hurricane or an >airplane crash, but "Precedence-related Services in the Internet". > >Would it make sense, in this recharter, to call it "Preferential >Services" or some such thing? > >_______________________________________________ >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-bounces@ietf.org Mon Jul 31 15:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWf-0004wg-7S; Mon, 31 Jul 2006 15:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWe-0004wW-8B for ieprep@ietf.org; Mon, 31 Jul 2006 15:34:04 -0400 Received: from mail.manske.org ([65.127.251.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7dWb-0001gd-OS for ieprep@ietf.org; Mon, 31 Jul 2006 15:34:04 -0400 Received: from mail.manske.org (localhost.manske.org [127.0.0.1]) by mail.manske.org (8.13.6/8.13.4) with ESMTP id k6VJXxHE021699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Jul 2006 14:33:59 -0500 (CDT) (envelope-from hcb@layer3arts.com) Received: (from nobody@localhost) by mail.manske.org (8.13.6/8.13.4/Submit) id k6VJXxQs021698 for ieprep@ietf.org; Mon, 31 Jul 2006 14:33:59 -0500 (CDT) (envelope-from hcb@layer3arts.com) X-Authentication-Warning: mail.manske.org: nobody set sender to hcb@layer3arts.com using -f Received: from 24-182-173-239.dhcp.stls.mo.charter.com (24-182-173-239.dhcp.stls.mo.charter.com [24.182.173.239]) by webmail.layer3arts.com (IMP) with HTTP for ; Mon, 31 Jul 2006 14:33:59 -0500 Message-ID: <1154374439.44ce5b2710cad@webmail.layer3arts.com> Date: Mon, 31 Jul 2006 14:33:59 -0500 From: "Howard C. Berkowitz" To: ieprep@ietf.org Subject: RE: [Ieprep] Preferential Services References: <20031409.1154372674520.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> In-Reply-To: <20031409.1154372674520.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 24.182.173.239 X-manske.org-MailScanner-Information: Please contact the ISP for more information X-manske.org-MailScanner: Found to be clean X-manske.org-MailScanner-From: hcb@layer3arts.com X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Quoting Janet Gunn : > I have a similar reaction to Stu's. > > "Preferential Services" somehow loses the "it is for your own good", or "for > the greater good" connotation that goes with "Emergency Preparedness". Having spent time on the medical and other delivery sides of emergency services, the telco phrases "special service protection" or "special safeguarding measures" might be a start. Yes, I know the latter has other implications. For those of us with access to emergency responders, it may be well to ask them if any term comes to mind. I will ask my housemate, an emergency physician with extensive field radio communications experience. Most hospitals, for example, deliberately have at least one POTS line in each critical area that has a mechanical relay that flips it to a direct FXS if the PBX goes down. Unfortunately, I can't think of any general term used for this other than "the backup phone line when the PBX breaks". While the overall system is far too complex, I wonder if there might be useful language in the [US] National Communications Systems' Restoration Priority System? > > Janet > > -----Original Message----- > >From: "GOLDMAN, STUART O (STUART)" > >Sent: Jul 31, 2006 2:58 PM > >To: Fred Baker , ieprep@ietf.org > >Subject: RE: [Ieprep] Preferential Services > > > >Fred, > > > >When people think of "preferential services" often they may think of > >silver, gold, & platinum services such as the airlines have where you > >get preferential service by paying more, or doing more business with the > >service provider. Do we need a term that better reminds us of the more > >unique nature of the "IEPREP" users in that they provide a service > >during an emergency? > > > >Stuart Goldman > >Lucent Technologies > >sgoldman@lucent.com > >602 493 8438 > > > >-----Original Message----- > >From: Fred Baker [mailto:fred@cisco.com] > >Sent: Monday, July 31, 2006 10:54 AM > >To: ieprep@ietf.org > >Subject: [Ieprep] Preferential Services > > > >You know, I think one thing that trips this group up is in the title. > >The issue this Working Group is thinking about is not so much > >"Emergency use of the Internet", which is often about deploying a new > >network when the usual one has been smashed by a hurricane or an > >airplane crash, but "Precedence-related Services in the Internet". > > > >Would it make sense, in this recharter, to call it "Preferential > >Services" or some such thing? > > > >_______________________________________________ > >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 > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep