From ieprep-bounces@ietf.org Tue Jun 06 19:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkqM-0007tt-9x; Tue, 06 Jun 2006 19:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkqK-0007tg-Pc; Tue, 06 Jun 2006 19:20:12 -0400 Received: from hermes.hosts.co.uk ([212.84.175.24] helo=minerva.hosts.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkqJ-0000mv-EY; Tue, 06 Jun 2006 19:20:12 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by minerva.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Fnkph-0002lX-Hg; Wed, 07 Jun 2006 00:19:34 +0100 In-Reply-To: <20060606122153.B7702@openss7.org> References: <20060606121528.A7702@openss7.org> <28F05913385EAC43AF019413F674A0170DE0C7F9@OCCLUST04EVS1.ugd.att.com> <20060606122153.B7702@openss7.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57110167-E0A5-4AB6-BAD5-A78AED814D3D@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Date: Tue, 6 Jun 2006 19:19:29 -0400 To: bidulock@openss7.org X-Mailer: Apple Mail (2.750) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ieprep@ietf.org, andren@ncs.gov, tsvwg , nguyena@ncs.gov Subject: [Ieprep] ETS (was Re: [Tsvwg] : Preemption scope) 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 just to note, the following RFC documents contain text on Emergency Telecommunications Service (ETS). rfc-3487: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) rfc-3689: General Requirements for Emergency Telecommunication Service (ETS) rfc-3690: IP Telephony Requirements for Emergency Telecommunication Service (ETS) rfc-4190: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony rfc-4375: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain rfc-4412: Communications Resource Priority for the Session Initiation Protocol (SIP) rfc-4542: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite I've cc'ed the IEPREP list since nearly all of the above documents came from that group. I kindly ask that if people choose to continue the discussion on ETS, please drop the TSVWG from the cc list and continue it on IEPREP. -ken On Jun 6, 2006, at 2:21 PM, Brian F. G. Bidulock wrote: > Martin, > > Dolly, Martin C, ALABS wrote: (Tue, 06 Jun 2006 > 13:18:47) >> TDR is the international service, where ETS is a national service >> (e.g., >> USA) > > As a general rule Canada adopts US terminology over International > terminology in telecommunications, or make ups their own terms. > > It is likely do to the proximity and friendly nature of the two > countries. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 06 19:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlMb-0007ZU-FA; Tue, 06 Jun 2006 19:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlMZ-0007ZE-B4; Tue, 06 Jun 2006 19:53:31 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnlMX-0004EZ-Nq; Tue, 06 Jun 2006 19:53:31 -0400 Received: from ns.pigworks.openss7.net (IDENT:b9DerVvvGSZ1QyJJF1JWd7ZK1hJpNzrk@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k56NrSq22425; Tue, 6 Jun 2006 17:53:28 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k56NrSq13393; Tue, 6 Jun 2006 17:53:28 -0600 Date: Tue, 6 Jun 2006 17:53:28 -0600 From: "Brian F. G. Bidulock" To: ken carlberg Message-ID: <20060606175328.A13072@openss7.org> Mail-Followup-To: ken carlberg , tsvwg , ieprep@ietf.org References: <20060606121528.A7702@openss7.org> <28F05913385EAC43AF019413F674A0170DE0C7F9@OCCLUST04EVS1.ugd.att.com> <20060606122153.B7702@openss7.org> <57110167-E0A5-4AB6-BAD5-A78AED814D3D@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <57110167-E0A5-4AB6-BAD5-A78AED814D3D@g11.org.uk>; from carlberg@g11.org.uk on Tue, Jun 06, 2006 at 07:19:29PM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tsvwg , ieprep@ietf.org Subject: [Ieprep] Re: ETS (was Re: [Tsvwg] : Preemption scope) X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org ken, ken carlberg wrote: (Tue, 06 Jun 2006 19:19:29) > I've cc'ed the IEPREP list since nearly all of the above documents > came from that group. I kindly ask that if people choose to continue > the discussion on ETS, please drop the TSVWG from the cc list and > continue it on IEPREP. Well, RFC 4190 section 4.3 explicitly scopes out network traffic engineering in support of ETS. Also, from the ieprep charter: "It is out of scope for this working group to do protocol or protocol feature development." Whereas, as you should known as an author, draft-lefaucheur-emergency-rsvp-01 clearly indicates: "This document specifies RSVP extensions necessary for supporting such admission priority capabilities." I am confused by your request to drop tsvwg from the cc list: Is not RSVP protocol and protocol feature development within the tsvwg charter? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 06 20:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlmC-0004Zr-7T; Tue, 06 Jun 2006 20:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlmA-0004ZZ-H7; Tue, 06 Jun 2006 20:19:58 -0400 Received: from athena.hosts.co.uk ([212.84.175.19] helo=hermes.hosts.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnlm8-0007iI-8S; Tue, 06 Jun 2006 20:19:58 -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 1Fnlm7-0000H0-Om; Wed, 07 Jun 2006 01:19:56 +0100 In-Reply-To: <20060606175328.A13072@openss7.org> References: <20060606121528.A7702@openss7.org> <28F05913385EAC43AF019413F674A0170DE0C7F9@OCCLUST04EVS1.ugd.att.com> <20060606122153.B7702@openss7.org> <57110167-E0A5-4AB6-BAD5-A78AED814D3D@g11.org.uk> <20060606175328.A13072@openss7.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <565F3EEB-2A25-4CD2-A313-A6A6B2595E32@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Date: Tue, 6 Jun 2006 20:19:51 -0400 To: bidulock@openss7.org X-Mailer: Apple Mail (2.750) X-Spam-Score: -4.4 (----) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tsvwg , ieprep@ietf.org Subject: [Ieprep] Re: ETS (was Re: [Tsvwg] : Preemption scope) 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 Brian, > I am confused by your request to drop tsvwg from the cc list: Is not > RSVP protocol and protocol feature development within the tsvwg > charter? Yes, I quite agree with the point you make in your above question. On the other hand, in my view a discussion about ETS itself is informational in nature, and that is what I wished to move (if necessary) to IEPREP. I may have been too pessimistic in feeling that any continued discussion on ETS will become protracted and philosophical in nature. I'll respect your wishes and leave tsvwg on. In any case, hopefully pointing out the previous RFCs has been helpful for you. cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jun 07 02:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnrXH-00014d-PS; Wed, 07 Jun 2006 02:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnrXF-00014P-IJ; Wed, 07 Jun 2006 02:28:57 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnrXD-0000T1-4U; Wed, 07 Jun 2006 02:28:57 -0400 Received: from ns.pigworks.openss7.net (IDENT:R6/E2TdE/wkjEq/USo3Fksz0aQyZLY9I@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k576Sqq32263; Wed, 7 Jun 2006 00:28:52 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k576SpV17729; Wed, 7 Jun 2006 00:28:51 -0600 Date: Wed, 7 Jun 2006 00:28:51 -0600 From: "Brian F. G. Bidulock" To: Janet P Gunn Message-ID: <20060607002851.A16971@openss7.org> Mail-Followup-To: Janet P Gunn , tsvwg@ietf.org, ieprep@ietf.org References: <20060606175824.B13072@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jgunn6@csc.com on Tue, Jun 06, 2006 at 10:33:35PM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tsvwg@ietf.org, ieprep@ietf.org Subject: [Ieprep] Re: [Tsvwg] : Preemption scope X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Janet, Janet P Gunn wrote: (Tue, 06 Jun 2006 22:33:35) > > It also says explicitly "Our reasoning and conclusions set forth above do > not necessarily extend to other priority schemes " > > I agree it would be a whole lot cleaner if there was somewhere that > explicitly SAID "preemption is not permitted". > > But it is not that hard to "read between the lines" the IMPLICIT assumption > that "preemption is not permitted". > > From a practical matter, the fact that all the carriers BELIEVE "preemption > is not permitted" is sufficient ( at least until the FCC comes out with an > explicit statement) to ensure that preemption is not going to be offered by > the US carriers. > Thank you for taking the time to humor me with the details! I think that I have some understanding of the predicament now from your excellent explanation. Nevertheless, does not calling preemption "unlawful" beg the question? Also, it appears that the preemption that was excluded from PAS was preempting "established" calls. Do you recall there anywhere being a definition of when a call is "established"? Barring such a definition, one, I suppose, could assume that once participants in the call have exchanged greetings that it is established. Because RSVP call admission is performed long before this point, there is a period of time after RSVP admits the call until the RTP channel is established and operational that RSVP could "preempt" the admission without preempting an "established" call. In fact, during a disaster which has stimulated a mass calling event, this is a critical period. > It also says explicitly "Our reasoning and conclusions set forth above do > not necessarily extend to other priority schemes " Would not that also exclude, preemption or not, any scheme not precisely PAS? ETS for RSVP is certainly not precisely PAS. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jun 07 04:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntSx-0003sj-IJ; Wed, 07 Jun 2006 04:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntSw-0003sW-3N; Wed, 07 Jun 2006 04:32:38 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FntSu-0007NL-LH; Wed, 07 Jun 2006 04:32:38 -0400 Received: from ns.pigworks.openss7.net (IDENT:WBM7dmV6fJm3ZaAiOmgfOad+dJI/EWVR@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k578WZq02313; Wed, 7 Jun 2006 02:32:35 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k578WZW19322; Wed, 7 Jun 2006 02:32:35 -0600 Date: Wed, 7 Jun 2006 02:32:35 -0600 From: "Brian F. G. Bidulock" To: Fil Dickinson Message-ID: <20060607023235.B16971@openss7.org> Mail-Followup-To: Fil Dickinson , "Francois Le Faucheur (flefauch)" , tsvwg@ietf.org, ieprep@ietf.org References: <799B0CDA650143429C5EA103965B59F80224A640@shqw2ke001.optus.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <799B0CDA650143429C5EA103965B59F80224A640@shqw2ke001.optus.com.au>; from Fil.Dickinson@optus.com.au on Wed, Jun 07, 2006 at 01:33:50PM +1000 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Francois Le Faucheur \(flefauch\)" , tsvwg@ietf.org, ieprep@ietf.org Subject: [Ieprep] Re: [Tsvwg] : Preemption scope X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ieprep-bounces@ietf.org Fil, Fil Dickinson wrote: (Wed, 07 Jun 2006 13:33:50) > > In the draft under the section 2.1.1 and 2.1.2 (the MAM and RDM models) > you use the phrase "...This is not expected to occur (or to occur > extremely rarely)". I agree with this when we are talking about networks > in a normal operational state, but dissagree when the network has > elements that have failed. As we are talking about ETS here I think it > is risky to assume that the network is operating normally, because it is > possible that the event that has resulted in ETS calls being made has > damaged the network and limitted it's capacity whilst at the same time > placed further demands on it from people desperate for information. > I agree that the authors should not comment on the probability of a given scenario in the proposed solution for the lack of engineering guidelines and operational experience necessary to assess the likelihood. Operational experience from the telephone network shows the opposite of what you might expect for several reasons: - disasters/emergencies are not likely to occur during the high day busy hour. (e.g. 9:00 am on Mother's Day). - normal traffic (and the reasons for it) tend to be suspended during the disaster/emergency. - operational network capacity (bandwidth) of common equipment tends to reduce as result of the disaster and damaged equipment (calls are simply not able to be established at the session level). OTOH at the session level, experience shows that the increase in call attempts to specific destinations increases dramatically and can be viewed as one or more mass calling event. 1. The call attempt (and, worse, reattempt) rate by individuals within the affected area to E911 or well known numbers of other official agencies (fire, police, etc) can rise dramatically. 2. The call attempt (and, worse, reattempt) rate by individuals outside the affected area attempting to call into the affected area rises dramatically (those, as you say, desperate for information, usually about loved ones in the affected area). (2), above, can be (and normally is) handled through the proper application of network controls in an orderly response remote from the affected area. (1), above, is very problematic to agencies local to the affected area in attempting to deal with the situtation. For example, although E911 trunks are dedicated from each local exchange, if 30,000 subscribers go off-hook and dial 911, anyone picking up the phone is lucky if they even get dial-tone. This makes it difficult, for example, for a fire-station in the area to call the Mayor's office. Nevertheless, the draft addresses only the network level, and it is up to the session level (such as described in the ieprep RFCs) to deal with that situation. Also, it is the responsibility of higher layer systems to alter network allocations in accordance with prevailing conditions. Again, after describing all possible scenarios, I agree that the draft authors should not then have commented on the likelihood of one or another without sufficient operational experience to support those statements. Telephone network operational experience might not be very applicable to Internet telephony as each system will likely perform differently when pushed to their breaking points. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Jun 09 09:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh2x-0000KF-NZ; Fri, 09 Jun 2006 09:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh2w-0000IY-1B; Fri, 09 Jun 2006 09:29:06 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fogq1-0004xN-NH; Fri, 09 Jun 2006 09:15:47 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (8.12.11/Switch-3.1.0) with ESMTP id k59DFi5o022008; Fri, 9 Jun 2006 09:15:45 -0400 (EDT) In-Reply-To: <20060607002851.A16971@openss7.org> To: bidulock@openss7.org X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 9 Jun 2006 09:15:43 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/09/2006 09:14:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tsvwg@ietf.org, ieprep@ietf.org Subject: [Ieprep] Re: [Tsvwg] : Preemption scope 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 line -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "Brian F. G. Bidulock" wrote on 06/07/2006 02:28:51 AM: > Janet, > > > Also, it appears that the preemption that was excluded from PAS was > preempting "established" calls. Do you recall there anywhere being a > definition of when a call is "established"? I don't know about a "definition", but, from a practical perspective, in an SS7 network, you could consider it when the destination returns an ISUP Answer Message (ANM). In an IP network, you could consider it to be when "bearer packets" (as opposed to "signaling packets") start being transmitted. > > Barring such a definition, one, I suppose, could assume that once > participants in the call have exchanged greetings that it is > established. Because RSVP call admission is performed long before this > point, there is a period of time after RSVP admits the call until the > RTP channel is established and operational that RSVP could "preempt" > the admission without preempting an "established" call. > > In fact, during a disaster which has stimulated a mass calling event, > this is a critical period. > > > It also says explicitly "Our reasoning and conclusions set forth above do > > not necessarily extend to other priority schemes " > > Would not that also exclude, preemption or not, any scheme not precisely > PAS? > > ETS for RSVP is certainly not precisely PAS. Absolutely. There is another "waiver" for the (landline) GETS features, but since i wasn't actively involved when it came out, it isn't sitting on my hard drive. There would need to be another "waiver" for any substantially new "special treatment". But the point is that everyone involved anticipates getting such a new waiver, as long as the new "special treatment" does not include "preemption". > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Jun 12 09:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCm-0003qQ-2q; Mon, 12 Jun 2006 09:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCk-0003lC-Do for ieprep@ietf.org; Mon, 12 Jun 2006 09:11:42 -0400 Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpm30-0007RL-Lk for ieprep@ietf.org; Mon, 12 Jun 2006 09:01:41 -0400 Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fpm2z-0007nQ-BD for ieprep@ietf.org; Mon, 12 Jun 2006 15:01:37 +0200 Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fpm2y-0004n6-00 for ; Mon, 12 Jun 2006 15:01:36 +0200 Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Mon, 12 Jun 2006 15:01:35 +0200 Date: Mon, 12 Jun 2006 15:01:35 +0200 From: Michael Schmeing To: ieprep@ietf.org Message-ID: <20060612130135.GD9821@nordhorn.fkie.fgan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN) User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: yes (FGAN VirusScan III) X-Scan-Signature: d2cf15bdfe212a5b41ac9f74731b6b74 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities 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 Hello all, sorry it took so long for me to get back to you, but it has been a very busy time. As there appears to be some interest in at least discussing the draft, I will start by summarising Dan Wingsīs input (both his submissions to the list and his suggestions he made directly to me) and give my view on these suggestions. Danīs first suggestion in his email directly to me was to use priority levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the length of the priority identifier is now limited to three digits, I think that is a valid suggestion. I plan to include that in the next version of the draft, unless someone can give good reasons to stick with the old scheme or use a completely new one. Another of Danīs suggestions in that email was to use the IANA to register the priority levels. He mentions that this would remove the problem with the Priority: and Precedence: header fields where some vendors use keywords and others (numerical) values. I am not sure it is really required to register the priority levels with IANA basically for two reasons: 1. The draft (and therefore the standard if it ever comes to that) defines the allowed value of the PRIORITY keyword to be only a numerical value. Thus the problem with the AFAIK not standardised header fields can not occur: Anyone conforming to the standard has to use numerical values according to the priority policy indicated. If anyone decides not to obey the standard, they would not care about IANA registration either. 2. The provided policy is only an example. Priority policy enforcement across administrative domain boundaries is difficult to say the least. For the general Internet, the most that I expect to be realistic is some form of Quality-of-Service, where Internet Providers would transport emails (or any other content) of some customers (which probably have to pay extra for this) more quickly than the traffic of other customers (keyword: net (non-)neutrality). They would define their own policy with their own priority levels for the use of email priorities, if they allow their customers to downgrade their service level on a per-email/per-connection basis. If, on the other hand, the group feels that we should go for IANA registration, that is fine with me. In that case, I would just ask someone to provide a wording example for this, because I have never done it yet. A problem Dan mentions in his email to the mailing list is the problem of authorisation. He asks the question of what will stop him from using highest priority on all emails and says that it can be solved within an administrative domain but probably not across them. As I have already indicated above, I see this problem as well. When I created the I-D, it was for a scenario of cooperating administrative domains and thus, this problem did not present itself: The domain administrations had agreed on a policy for the use of priorities. Of course, one thing preventing excessive use of high priorities is the size limit on high-priority emails. You can not put much data in two or four kilobyte, so you have to use lower priorities for larger emails. Other than that, I only have one rough idea so far how this issue could be addressed in a general case that I would like your opinion on: The policy could impose a frequency with which one sender may issue emails of the higher priorities. Together with the smaller size of high-priority emails that should guarantee at least some space for lower priority emails Best regards, Michael Schmeing -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Jun 12 12:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppJQ-00009X-Cx; Mon, 12 Jun 2006 12:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppJO-00009P-Gz for ieprep@ietf.org; Mon, 12 Jun 2006 12:30:46 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FppJN-0001EJ-QX for ieprep@ietf.org; Mon, 12 Jun 2006 12:30:46 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 12 Jun 2006 12:30:29 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006061212302925234 ; Mon, 12 Jun 2006 12:30:29 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 12 Jun 2006 12:30:29 -0400 Message-Id: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.us.saic.com> From: "King, Kimberly S." To: ieprep@ietf.org Date: Mon, 12 Jun 2006 12:30:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: d70738b58489ee14fb507f541b784688 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [Ieprep] Another version of a potential 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 We were asked to tighten up the potential new charter. Here is a start. Comments? ________________________ Internet Emergency Preparedness (ieprep) Charter 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 Mon Jun 12 14:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpqp2-0008AC-5T; Mon, 12 Jun 2006 14:07:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpqp0-00089w-IE for ieprep@ietf.org; Mon, 12 Jun 2006 14:07:30 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpqoz-0002Wg-93 for ieprep@ietf.org; Mon, 12 Jun 2006 14:07:30 -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 k5CI7ODx019789; Mon, 12 Jun 2006 14:07:25 -0400 (EDT) In-Reply-To: <20060612130135.GD9821@nordhorn.fkie.fgan.de> Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities To: Michael Schmeing X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Mon, 12 Jun 2006 14:07:22 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/12/2006 02:06:26 PM MIME-Version: 1.0 X-Spam-Score: 0.8 (/) 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: , Content-Type: multipart/mixed; boundary="===============0725518012==" Errors-To: ieprep-bounces@ietf.org --===============0725518012== Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 DQoNCg0KDQpJIGhhdmUgYSBidW5jaCBvZiBkZXRhaWxlZCBjb21tZW50cywgd2hpY2ggSSBhbSBz dGlsbCB3b3JraW5nIG9uLCBidXQgSQ0KYWxzbyBoYXZlIHNvbWUgaGlnaCBsZXZlbCBxdWVzdGlv bnMvY29tbWVudHMsIHdoaWNoIEkgd2lsbCBpbmNsdWRlIGhlcmUuDQoNClRoaXMgSUQgY2xlYXJs eSBhZGRyZXNzZXMgYSBzZXQgb2YgZW1haWwgcmVxdWlyZW1lbnRzIChub3QgZnVsbHkgZG9jdW1l bnRlZA0KaGVyZSkgdGllZCB0byB0aGUgVVMgRG9ELg0KDQpXaGlsZSB0aGV5IGhhdmVuJ3QgYmVl biBzZXQgZG93biB5ZXQsIGl0IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlcmUgd2lsbCBiZQ0KYSBz ZXQgb2YgcHJpb3JpdHkgcmVxdWlyZW1lbnRzIGZvciBOUy9FUCAoTmF0aW9uYWwgU2VjdXJpdHkg YW5kIEVtZXJnZW5jeQ0KUHJlcGFyZWRuZXNzKSBlbWFpbCwgd2hpY2ggYXJlIGxpa2VseSB0byBi ZSBzb21ld2hhdCBkaWZmZXJlbnQgZnJvbSB0aGUNCm1pbGl0YXJ5IHJlcXVpcmVtZW50cy4gIEFu ZCBJIGV4cGVjdCB0aGVyZSB3aWxsIGJlIG90aGVyIHJlcXVpcmVtZW50cyBmcm9tDQpvdGhlciBw YXJ0cyBvZiB0aGUgd29ybGQuDQoNCkl0IHdvdWxkIGJlIG5pY2UgaWYgd2UgaGFkIGEgbW9yZSBn ZW5lcmFsIHNvbHV0aW9uLCB3aGljaCBjb3VsZCBlbmNvbXBhc3MgYQ0KdmFyaWV0eSBvZiByZWxh dGVkIGJ1dCBkaXN0aW5jdCByZXF1aXJlbWVudHMuDQoNClRoZSBTSVAgUlBIIChSRkM0NDEyKSAo b24gd2hpY2ggdGhlIElFUFJFUCBXRyBoYWQgc2lnbmlmaWNhbnQgaW5wdXQpIGhhcyBhDQptb3Jl IGdlbmVyYWwgc3RydWN0dXJlIHdoaWNoIGFsbG93cyBpdCB0byBlbmNvbXBhc3MgYm90aCB0aGUg KHByZS1lbXB0aW9uDQpiYXNlZCkgTUxQUCBmdW5jdGlvbmFsaXR5IGFuZCB0aGUgKHF1ZXVpbmcg YmFzZWQpR0VUUy9XUFMvRVRTDQpmdW5jdGlvbmFsaXR5LCBieSB0aGUgdXNlIG9mIChJQU5BIHJl Z2lzdGVyZWQpIG5hbWVzcGFjZXMuDQoNCklzIHRoZXJlIGEgcmVhc29uIHdoeSB3ZSBjb3VsZG4n dCBkbyBzb21ldGhpbmcgYW5hbG9nb3VzIGZvciBlbWFpbD8NCg0KU29tZSBvZiB0aGUgc3BlY2lm aWMgYXJlYXMgd2hlcmUgdGhlcmUgbWlnaHQgYmUgIGRpZmZlcmVudCByZXF1aXJlbWVudHM6DQoN ClRoaXMgZHJhZnQgZm9jdXNlcyBvbiDigJxyYXBpZCBkZWxpdmVyeeKAnSAgb3Ig4oCcb3JkZXIg b2YgZGVsaXZlcnnigJ0gcmF0aGVyIHRoYW4NCuKAnGhpZ2ggcHJvYmFiaWxpdHkgb2YgZGVsaXZl cnnigJ0uICBJbiBmYWN0LCBpdCBzdGlwdWxhdGVzIHRoYXQsIGZvciBzb21lDQpwcmlvcml0eSBs ZXZlbHMsIGlmIHRoZSBlbWFpbCBjYW5ub3QgYmUgZGVsaXZlcmVkIOKAnHdpdGggcHJpb3JpdHni gJ0sIGl0DQpzaG91bGQgYmUgcmVqZWN0ZWQgKHNlZSBzZWN0aW9uIDYuNS43KS4gIEkgY2FuIHRo aW5rIG9mIG1hbnkgc2l0dWF0aW9ucw0Kd2hlcmUgaXQgaXMgYmV0dGVyIHRvIGNvbnRpbnVlIHdp dGggbm9uLXByaW9yaXR5IGRlbGl2ZXJ5IHRoYW4gdG8gcmVqZWN0IGFuDQplbWFpbC4NCg0KVGhl cmUgbWlnaHQgYmUgY2lyY3Vtc3RhbmNlcyBpbiB3aGljaCAicHJlZW1wdGlvbiIgb2YgIGN1cnJl bnQgZW1haWwNCnRyYW5zbWlzc2lvbnMgaXMgbm90IGRlc2lyZWQsIGJ1dCAibW92aW5nIGhpZ2gg cHJpb3JpdHkgZW1haWxzIHRvIHRoZSBmcm9udA0Kb2YgdGhlIHF1ZXVlIiBJUyBkZXNpcmFibGUu ICBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSBtZWNoYW5pc20gY291bGQNCnN1cHBvcnQgYm90aCBh cHByb2FjaGVzLg0KDQpJIHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgbGltaXRpbmcgdGhl IHNpemUgb2YgdGhlIGhpZ2ggcHJpb3JpdHkNCmVtYWlscywgYnV0IEkgY2FuIHRoaW5rIG9mIHNp dHVhdGlvbnMgd2hlcmUgb3RoZXIgbWVjaGFuaXNtcyBtaWdodCBiZSBhDQptb3JlIGFwcHJvcHJp YXRlIHdheSB0byBtYWtlIHN1cmUgdGhhdCAgdGhlIG92ZXJhbGwgImhpZ2ggcHJpb3JpdHkiIHZv bHVtZQ0KcmVtYWlucyBsb3cuDQoNCkN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mICBNTFBQLCBl TUxQUCwgV1BTLCBhbmQgUlBIIHVzZSAwIHRvIHJlcHJlc2VudA0KdGhlIGhpZ2ggcHJpb3JpdHkg Z3JvdXAsIHdpdGggMS4yLjMuNCwgZXRjIHJlcHJlc2VudGluZyBzdWNjZXNzaXZlbHkgbG93ZXIN CnByaW9yaXRpZXMuICBXaGF0IGlzIHRoZSByYXRpb25hbGUgZm9yIHR1cm5pbmcgdGhpcyB1cHNp ZGUgZG93biBhbmQgdXNpbmcgMA0KdG8gcmVwcmVzZW50ICJub24tcHJpb3JpdHkiPw0KDQpXaHkg d291bGQgdGhlIGZhY3QgdGhhdCBhIG1lc3NhZ2UgaXMgdW5jbGFzc2lmaWVkIGltcGx5IHRoYXQg aXQgaXMgbG93ZXINCnByaW9yaXR5PyAgSSBkb24ndCBzZWUgdGhlIGNvcnJlbGF0aW9uLg0KDQoN ClRoYW5rcywNCg0KSmFuZXQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdl LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCmRlbGV0ZSB3 aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0 YWtlIGluDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFp bCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNv bnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuDQphZ3JlZW1lbnQgb3Ig Z292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1t YWlsDQpmb3Igc3VjaCBwdXJwb3NlLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --===============0725518012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep --===============0725518012==-- From ieprep-bounces@ietf.org Mon Jun 12 15:00:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprdz-0004Pd-Pz; Mon, 12 Jun 2006 15:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprdy-0004Ow-TW for ieprep@ietf.org; Mon, 12 Jun 2006 15:00:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprdy-00082y-BH for ieprep@ietf.org; Mon, 12 Jun 2006 15:00:10 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 12:00:09 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824175000:sNHT55950388" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5CJ09G6027884; Mon, 12 Jun 2006 12:00:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CJ09cL020245; Mon, 12 Jun 2006 12:00:09 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 15:00:08 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 15:00:08 -0400 Message-Id: <4.3.2.7.2.20060612135818.040b68b0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jun 2006 14:00:06 -0500 To: "King, Kimberly S." , ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] Another version of a potential IEPREP charter In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01188600@0015-its-exmb02.u s.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Jun 2006 19:00:08.0411 (UTC) FILETIME=[6C6BE2B0:01C68E52] DKIM-Signature: a=rsa-sha1; q=dns; l=7245; t=1150138809; x=1151002809; c=relaxed/simple; s=sjdkim7001; 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:Re=3A=20[Ieprep]=20Another=20version=20of=20a=20potential=20IEPREP=20cha rter; X=v=3Dcisco.com=3B=20h=3Dle3aD6e3US15oBG3z9RUKejBNXg=3D; b=JtWX3jlzsEtOf7UnkSMHCd4GCVnbrpmry1rXVC5K9M7+UJ3oH0TFph7UOcV/5PNlcN6F6BrC wcjsKhJctj23JGAx+nyGxuKBMAnsjZyJ2gOhacI88cW0qtRQ4tz3Um1k; Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 I would add at the bottom that "...we will consider rechartering for new work if there is WG consensus to do so, or shut the WG down." Otherwise, this looks good. At 12:30 PM 6/12/2006 -0400, King, Kimberly S. wrote: >We were asked to tighten up the potential new charter. Here is a start. >Comments? > >________________________ > > > > > > > >Internet Emergency Preparedness (ieprep) Charter > > > >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 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 00:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0ro-0004zt-4G; Tue, 13 Jun 2006 00:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0rn-0004zo-3U for ieprep@ietf.org; Tue, 13 Jun 2006 00:51:03 -0400 Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq0rk-0003Oo-FV for ieprep@ietf.org; Tue, 13 Jun 2006 00:51:03 -0400 Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fq0ri-0002nY-OU; Tue, 13 Jun 2006 06:50:58 +0200 Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fq0rh-0003Ld-00; Tue, 13 Jun 2006 06:50:57 +0200 Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Tue, 13 Jun 2006 06:50:57 +0200 Date: Tue, 13 Jun 2006 06:50:57 +0200 From: Michael Schmeing To: "Nguyen, An P CIV NCS NC2" Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities (UNCLASSIFIED) Message-ID: <20060613045057.GA2448@nordhorn.fkie.fgan.de> References: <9B4320CC9BC1D847AFFA97F25A422A59114AE9@vanualevu.disanet.disa-u.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59114AE9@vanualevu.disanet.disa-u.mil> Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN) User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: yes (FGAN VirusScan III) X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Mon, Jun 12, 2006 at 10:43:42AM -0400, Nguyen, An P CIV NCS NC2 wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Michael, > > I have the following questions: > > 1. Is this draft intended for DOD only? When I first scanned the draft, > my impression is that it's written for DoD. If not, the text should be > rewritten to reflect it. An, you are right: The draft actually was written as part of an ongoing research project from the german MoD. This of course shows in the wording. But we want its scope to be broadened beyond this. So yes, the text should be rewritten. > > 2. I know SMTP uses a store and forward approach, with messages being > held at a sequence of MTAs (Message Transfer Agents) en route from > originator to recipient. I think messages with higher priority would get > processed first ( while mgs with lower priority might have to wait in > the queue). That at least ist the general idea. > They would be rerouted to the another MTAs because of failed links > (e.g., dns problem, layer 3 disconnect, etc). And you use SMTP > priority values to differentiate QoS for different messages. In > order for this scheme to work, you would have a policy that forces > all MTAs within a admin domain to accept/honor these priority > values; otherwise, this would not work at all. At least in the military domain (especially NATO) this is how it is supposed to work with their X.400 based systems. > Let's assume that you can do it in a single admin domain. How are > you going to deal "global" configurations in MTA's in multiple > domains so that you would get some levels of QoS? You are touching here one of the major points that need to be clarified before the extension can be standardized. I donīt have any clear idea of what needs to or can be done with respect to this question. Regards, Michael -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** > -----Original Message----- > From: Michael Schmeing [mailto:schmeing@fgan.de] > Sent: Monday, June 12, 2006 9:02 AM > To: ieprep@ietf.org > Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities > > > Hello all, > > sorry it took so long for me to get back to you, but it has been a > very busy time. As there appears to be some interest in at least > discussing the draft, I will start by summarising Dan Wingsīs input > (both his submissions to the list and his suggestions he made directly > to me) and give my view on these suggestions. > > Danīs first suggestion in his email directly to me was to use priority > levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the > length of the priority identifier is now limited to three digits, I > think that is a valid suggestion. I plan to include that in the next > version of the draft, unless someone can give good reasons to stick > with the old scheme or use a completely new one. > > Another of Danīs suggestions in that email was to use the IANA to > register the priority levels. He mentions that this would remove the > problem with the Priority: and Precedence: header fields where some > vendors use keywords and others (numerical) values. > > I am not sure it is really required to register the priority levels > with IANA basically for two reasons: > 1. The draft (and therefore the standard if it ever comes to that) > defines the allowed value of the PRIORITY keyword to be only a > numerical value. Thus the problem with the AFAIK not standardised > header fields can not occur: Anyone conforming to the standard has > to use numerical values according to the priority policy > indicated. If anyone decides not to obey the standard, they would > not care about IANA registration either. > 2. The provided policy is only an example. Priority policy enforcement > across administrative domain boundaries is difficult to say the > least. For the general Internet, the most that I expect to be > realistic is some form of Quality-of-Service, where Internet > Providers would transport emails (or any other content) of some > customers (which probably have to pay extra for this) more quickly > than the traffic of other customers (keyword: net > (non-)neutrality). They would define their own policy with their > own priority levels for the use of email priorities, if they allow > their customers to downgrade their service level on a > per-email/per-connection basis. > If, on the other hand, the group feels that we should go for IANA > registration, that is fine with me. In that case, I would just ask > someone to provide a wording example for this, because I have never > done it yet. > > A problem Dan mentions in his email to the mailing list is the problem > of authorisation. He asks the question of what will stop him from > using highest priority on all emails and says that it can be solved > within an administrative domain but probably not across them. > > As I have already indicated above, I see this problem as well. > > When I created the I-D, it was for a scenario of cooperating > administrative domains and thus, this problem did not present itself: > The domain administrations had agreed on a policy for the use of > priorities. > > Of course, one thing preventing excessive use of high priorities is > the size limit on high-priority emails. You can not put much data in > two or four kilobyte, so you have to use lower priorities for larger > emails. > > Other than that, I only have one rough idea so far how this issue > could be addressed in a general case that I would like your opinion > on: The policy could impose a frequency with which one sender may > issue emails of the higher priorities. Together with the smaller size > of high-priority emails that should guarantee at least some space for > lower priority emails > > > > Best regards, > Michael Schmeing > -- > **************************************************** > | Michael Schmeing E-Mail: schmeing@fgan.de | > | FGAN/FKIE Tel: (+49) 228/9435 593 | > | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | > | D-53343 Wachtberg, Germany | > **************************************************** > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > Classification: UNCLASSIFIED > Caveats: NONE > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 01:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1ox-00064Y-Or; Tue, 13 Jun 2006 01:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1ow-0005zS-KV for ieprep@ietf.org; Tue, 13 Jun 2006 01:52:10 -0400 Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1ou-0007UE-Tg for ieprep@ietf.org; Tue, 13 Jun 2006 01:52:10 -0400 Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fq1ot-0003FN-Ih; Tue, 13 Jun 2006 07:52:07 +0200 Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fq1os-0003nD-00; Tue, 13 Jun 2006 07:52:06 +0200 Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Tue, 13 Jun 2006 07:52:06 +0200 Date: Tue, 13 Jun 2006 07:52:06 +0200 From: Michael Schmeing To: Janet P Gunn Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities Message-ID: <20060613055205.GB2448@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN) User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: yes (FGAN VirusScan III) X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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 Mon, Jun 12, 2006 at 02:07:22PM -0400, Janet P Gunn wrote: > > > > > I have a bunch of detailed comments, which I am still working on, but I > also have some high level questions/comments, which I will include here. > > This ID clearly addresses a set of email requirements (not fully documented > here) tied to the US DoD. That is hardly surprising, since it was created during an ongoing research project for the German MoD as I have already said. > > While they haven't been set down yet, it is anticipated that there will be > a set of priority requirements for NS/EP (National Security and Emergency > Preparedness) email, which are likely to be somewhat different from the > military requirements. And I expect there will be other requirements from > other parts of the world. > > It would be nice if we had a more general solution, which could encompass a > variety of related but distinct requirements. Jan and I devided the I-D into two parts: A generic framwork and a policy. The framework (which is the main part of the draft) should allow for as much flexibility as possible. If there are restrictions defined in that part, that are not necessary or are too specific, they should be removed or rewritten. The policy in Sec. 6.5 on the other hand is intended to be a concrete example of some of the possibilities designers have when creating their own policy. It is clearly inspired (and targeted) at the Military Message Handling Systems (MMHS) of NATO as it stems from there. While the draft currently says this is the default policy, I have since come to doubt whether the policy is really fit for general use in the Internet. It may be a good idea to split the draft up into one for the framework and one for an example policy. > > The SIP RPH (RFC4412) (on which the IEPREP WG had significant input) has a > more general structure which allows it to encompass both the (pre-emption > based) MLPP functionality and the (queuing based)GETS/WPS/ETS > functionality, by the use of (IANA registered) namespaces. > > Is there a reason why we couldn't do something analogous for email? I donÂīt know these standards so I donÂīt know if it is possible for emails. But I think it should be. > > Some of the specific areas where there might be different requirements: > > This draft focuses on “rapid delivery” or “order of delivery” rather than > “high probability of delivery”. In fact, it stipulates that, for some > priority levels, if the email cannot be delivered “with priority”, it > should be rejected (see section 6.5.7). I can think of many situations > where it is better to continue with non-priority delivery than to reject an > email. As said above, Sec. 6.5 presents a specific policy. Give JanÂīs and my knowledge of military messaging, it seemed plausible that messages with higher priority are as well of higher sensitivity. Therefore we decided to split the defined priority levels up into the higher ones which may not be transferred with non-priority and the lower ones which may. For other scenarios the reasoning may be different and the decission may be another one. In this case, the applicable policy would just have to define when to continue with non-priority (or just a lower one?) and when to reject. Please bear in mind that the given policy is not meant to be an exhaustive example. You can make the algorithm deciding when to go non-priority and when to reject or do something else as complex as you like (or need to). As the general default (in case the policy does not deal with this topic), I feel that rejection is the right choice though. If you deploy priorities you have a reason to and thus silently going non-priority is probably not what you want. > > There might be circumstances in which "preemption" of current email > transmissions is not desired, but "moving high priority emails to the front > of the queue" IS desirable. It would be nice if the mechanism could > support both approaches. Indeed it would. And it should be this way either (so I would be thankfull for a suggestion of a better wording), but the final decision whether to preempt or just move to the top of the queue should by all means remain with the policy. > > I understand the rationale for limiting the size of the high priority > emails, but I can think of situations where other mechanisms might be a > more appropriate way to make sure that the overall "high priority" volume > remains low. Agreed. But the actual size limitation is (again) only in the policy. The framework just says that a size limitation is imposed, it is to be respected (or at least that what it should read like). In the military context, there are other means deployed, but we did not want to make the policy too complex. One these means is that they strictly limit the nature of messages that may be sent at highest priority (AFAIK in Germany only the message that an enemy division or corps has first been discovered may be sent at highest priority). > > Current implementations of MLPP, eMLPP, WPS, and RPH use 0 to represent > the high priority group, with 1.2.3.4, etc representing successively lower > priorities. What is the rationale for turning this upside down and using 0 > to represent "non-priority"? One of the conditions of the draft is that normal (i.e. non-prioritiezed) email from the Internet can still be handled. To achieve this, we need a unique way to identify such emails. The only sensible options Jan and I could think of were either to mandate that such emails MUST NOT have the priority keyword added to the recipients or to define a fixed identifier. We decided on the identifier approach because it was easier to implement. Originally, the length of the identifier was unlimited. That meant that 0 was the only number that was guaranteed not to punch a hole into the series of priority levels defined by any policy conforming to the framework. As the length of the priority identifier has been limited to three digits in the current version, it would be no problem to reverse the semantics of identifier (i.e. make lower numbers denote higher priorities). The non-priority would then be fixed to the value of 999. > > Why would the fact that a message is unclassified imply that it is lower > priority? I don't see the correlation. Neither do I. This is just an example of some constraints a policy may impose that inlude considerations from a content oriented perspective. > > > Thanks, > > Janet Thanks for the input, Michael -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 10:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9fc-0000il-9Z; Tue, 13 Jun 2006 10:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9fb-0000ig-7M for ieprep@ietf.org; Tue, 13 Jun 2006 10:15:03 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9fZ-0007Ql-Va for ieprep@ietf.org; Tue, 13 Jun 2006 10:15:03 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5DEF1vr027685 for ; Tue, 13 Jun 2006 09:15:01 -0500 (CDT) Received: from jrrosenberg-04.lucent.com (jrrosenberg-04.ih.lucent.com [135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5DEF1w23285; Tue, 13 Jun 2006 09:15:01 -0500 (CDT) Message-Id: <6.2.1.2.0.20060613090916.0337b380@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 13 Jun 2006 09:15:00 -0500 To: ieprep@ietf.org From: John Rosenberg In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ieprep] Re: Discussion of Internet-Draft for SMTP priorities 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 At 11:51 PM 6/12/2006, Janet Gunn wrote: >Date: Mon, 12 Jun 2006 14:07:22 -0400 >From: Janet P Gunn > >Current implementations of MLPP, eMLPP, WPS, and RPH use 0 to represent >the high priority group, with 1.2.3.4, etc representing successively lower >priorities. What is the rationale for turning this upside down and using 0 >to represent "non-priority"? The current DISA specification for MLPP on VoIP networks specifies RPH r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of priority (e.g. 0 = Routine and 9 = F-O-O). John Rosenberg _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 10:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqA4R-00040B-6I; Tue, 13 Jun 2006 10:40:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqA4P-0003wL-U3 for ieprep@ietf.org; Tue, 13 Jun 2006 10:40:41 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqA4O-0000Va-Lg for ieprep@ietf.org; Tue, 13 Jun 2006 10:40:41 -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 k5DEedIb011804; Tue, 13 Jun 2006 10:40:40 -0400 (EDT) In-Reply-To: <6.2.1.2.0.20060613090916.0337b380@ihmail.ih.lucent.com> Subject: Re: [Ieprep] Re: Discussion of Internet-Draft for SMTP priorities To: John Rosenberg X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 13 Jun 2006 10:40:37 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/13/2006 10:39:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Yes, you are right, I forgot about that. I will refine my statement. RFC 4412 lists "4,3,2,1,0" as the "lowest to highest" ordering for q375, ets, and wps. q375 is, effectively, a form of MLPP. RFC 4412 lists text, rather than numeric values, for dsn and dsrn. eMLPP uses "4,3,2,1,0,B,A" as the "lowest to highest" So I think we need to have FLEXIBILITY in the ordering of the priority levels. 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- John Rosenberg To ieprep@ietf.org 06/13/2006 10:15 cc AM Subject [Ieprep] Re: Discussion of Internet-Draft for SMTP priorities At 11:51 PM 6/12/2006, Janet Gunn wrote: >Date: Mon, 12 Jun 2006 14:07:22 -0400 >From: Janet P Gunn > >Current implementations of MLPP, eMLPP, WPS, and RPH use 0 to represent >the high priority group, with 1.2.3.4, etc representing successively lower >priorities. What is the rationale for turning this upside down and using 0 >to represent "non-priority"? The current DISA specification for MLPP on VoIP networks specifies RPH r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of priority (e.g. 0 = Routine and 9 = F-O-O). John Rosenberg _______________________________________________ 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 Tue Jun 13 12:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBI8-00043B-Rx; Tue, 13 Jun 2006 11:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBI8-000436-0W for ieprep@ietf.org; Tue, 13 Jun 2006 11:58:56 -0400 Received: from hermes.hosts.co.uk ([212.84.175.24] helo=pallas.hosts.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBI6-0001ne-Jk for ieprep@ietf.org; Tue, 13 Jun 2006 11:58:55 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by pallas.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1FqBHr-0002jc-2M; Tue, 13 Jun 2006 16:58:40 +0100 In-Reply-To: <20060612130135.GD9821@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities Date: Tue, 13 Jun 2006 11:58:48 -0400 To: Michael Schmeing X-Mailer: Apple Mail (2.750) X-Spam-Score: -4.4 (----) 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 Hello Michael, I would like to echo Janet's request of putting in place a prioritization field that is more extendable so that various sets of users could rely on different priority structures/values, but more importantly, different associated policies. The one major headache is that if you go down this road, I think your draft will require some significant changes. Janet mentioned RFC4412, whose structure is a string based BNF representation. If you would prefer a strictly numeric representation for the NameSpace.Value tuple first mentioned in RFC4412, you should look at NSIS QSPEC draft (which I believe is under WG last call) http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt. In either case, you can leverage previous work and choose to do so either in alphanumeric or strictly numeric form and not have to worry about specifying your own IANA registry. One minor point involves Section 4.1 You mention using the ToS field as a means of supporting expedited transfer. Its probably best to update that text with RFC-3168, which deprecates ToS (and precedence fields) in favor of the Differentiated Services field. Also, I would disagree with your statement that your proposed field does not "raise any security issues not already endemic in electronic mail". Currently, with FIFO based system we have a system where everyone experiences a form of best effort in obtaining MTA resources. But with your proposed extension, one introduces a case where email labeled as low priority can be indefinitely starved of resources. In some systems/domains, this may be desired. In others, one may want a more weighted round robin servicing so that priorities correlate to the weights, but eventually, all message queues would be serviced. Outside of that, it would seem desirable for your draft to at least advocate some measures of security like S/MIME for header protection (rfc-3851), and possibly the use of AUTH. Finally, in section 6.5.3, you state some specific delivery time constraints. I'm curious as to where you came up with those numbers -- it would probably be helpful to add some context. Some deployed underlying HF and ULF systems would have a hard time meeting your constraints depending on message size. My personal feeling is that it may be best to move text like that and 4.1 into an appendix outside of that, its a nice document for discussion -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 13:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD2h-0003mX-S8; Tue, 13 Jun 2006 13:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD1S-0002un-7z for ieprep@ietf.org; Tue, 13 Jun 2006 13:49:50 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCpY-0001Pt-8M for ieprep@ietf.org; Tue, 13 Jun 2006 13:37:32 -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 k5DHbVO8017095; Tue, 13 Jun 2006 13:37:31 -0400 (EDT) To: ieprep@ietf.org X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 13 Jun 2006 13:37:28 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/13/2006 01:36:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "Taylor, Carollyn D CIV NCS NC2" , stephen.perschau@dhs.gov Subject: [Ieprep] (Forwarded) alternate version of revised 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 I have been asked to send this to the IEPREP list on behalf of Carol-Lyn Taylor and Stephen Perschau (both of NCS). 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM ----- > Sent on behalf of Stephen Perschau: > > Attached is a version of the proposed draft new charter that I would > like to see discussed. It is different from the one sent by Dr. > King. This version of the proposed draft charter focuses on DoD > aspects. MLPP is not an intrinsic aspect of an ETS although it can > be used where permitted. MLPP is used on a daily basis by DoD in > their enterprise network and the charter should reflect that fact. > Stephen Perschau > ********************************************************************* > MTW (MLPP That Works) Formally (ieprep) Charter > > Description of Working Group: Effective telecommunications > capabilities in enterprise networks (private commercial or > government/military networks) are necessary for normal day-to-day > operations. These enterprise capabilities can also be used to > facilitate response and recovery operations for emergency events > including natural disasters (e.g., hurricanes, floods, earthquakes) > and those created by man (e.g., terrorist attacks, combat situations > or wartime events). > > The WG will address proactive measures to deal with emergency events > from the following perspectives: > > 1. A government/military telecommunications network that retains > sole administration 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. > The following apply: > 1. 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' > 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 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. > > 2. 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 > differing security levels, etc. that should be described before > mechanisms are proposed. The WG will document the context for > implementing solutions. In addition, solutions must be developed > when appropriate. > > 3. While voice was the driving application in the past, preferential > treatment will need to be applied to all applications used in > response and recovery operations. Preferential treatment must be > applied to real-time (e.g., voice) and non-real-time applications > (e.g., Text messaging, SMS) that share the same network. The WG will > document the preferential treatment mechanisms that are appropriate > for any essential communications. > > In the IETF, considerations for treatment and security of > communications for response and recovery operations 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. The WG will cooperate closely with these groups > and with those outside of the IETF such as ITU-T study groups. In > addition, the WG 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, the WG 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, the WG will prepare requirements and > discuss the extension of that protocol/mechanism or > protocols/mechanisms within the WG. > > Goals and Milestones: > > Aug 06 Submit an initial I-D of Requirements of Government/Military > Networks for Precedence and Preemption > > 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. > Jan 07 Submit 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). > > Classification: UNCLASSIFIED > Caveats: NONE > > Classification: UNCLASSIFIED > Caveats: NONE _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Jun 13 15:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEG7-00031k-RR; Tue, 13 Jun 2006 15:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEG7-00031f-2b for ieprep@ietf.org; Tue, 13 Jun 2006 15:09:03 -0400 Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEG5-00045I-4J for ieprep@ietf.org; Tue, 13 Jun 2006 15:09:03 -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); Tue, 13 Jun 2006 12:08:59 -0700 Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities From: Rex Buddenberg To: Michael Schmeing In-Reply-To: <20060612130135.GD9821@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> Content-Type: text/plain; charset=UTF-8 Date: Tue, 13 Jun 2006 12:08:41 -0700 Message-Id: <1150225721.17922.135.camel@north-latitude.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jun 2006 19:08:59.0626 (UTC) FILETIME=[D3769CA0:01C68F1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 coupling of possibly disparate efforts. Michael, Suggest you check out Common Alerting Protocol to avoid gratuitous incompatabilities. CAP is designed as a content framework (essentially an XML-based data dictionary) for alerting. E-mail is one, among many, means of delivery of such information. Here's the .sig from the discussion list that should have plenty of pointers: ------------- This list is for public discussion of the Common Alerting Protocol. This list is NOT part of the formal record of the OASIS Emergency Management TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=3Demergenc= y CAP-list mailing list CAP-list@lists.incident.com http://eastpac.incident.com/mailman/listinfo/cap-list This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. ------------- On Mon, 2006-06-12 at 15:01 +0200, Michael Schmeing wrote: > Hello all, >=20 > sorry it took so long for me to get back to you, but it has been a > very busy time. As there appears to be some interest in at least > discussing the draft, I will start by summarising Dan Wings=C2=B4s input > (both his submissions to the list and his suggestions he made directly > to me) and give my view on these suggestions. >=20 > Dan=C2=B4s first suggestion in his email directly to me was to use priori= ty > levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the > length of the priority identifier is now limited to three digits, I > think that is a valid suggestion. I plan to include that in the next > version of the draft, unless someone can give good reasons to stick > with the old scheme or use a completely new one. >=20 > Another of Dan=C2=B4s suggestions in that email was to use the IANA to > register the priority levels. He mentions that this would remove the > problem with the Priority: and Precedence: header fields where some > vendors use keywords and others (numerical) values. >=20 > I am not sure it is really required to register the priority levels > with IANA basically for two reasons: > 1. The draft (and therefore the standard if it ever comes to that) > defines the allowed value of the PRIORITY keyword to be only a > numerical value. Thus the problem with the AFAIK not standardised > header fields can not occur: Anyone conforming to the standard has > to use numerical values according to the priority policy > indicated. If anyone decides not to obey the standard, they would > not care about IANA registration either. > 2. The provided policy is only an example. Priority policy enforcement > across administrative domain boundaries is difficult to say the > least. For the general Internet, the most that I expect to be > realistic is some form of Quality-of-Service, where Internet > Providers would transport emails (or any other content) of some > customers (which probably have to pay extra for this) more quickly > than the traffic of other customers (keyword: net > (non-)neutrality). They would define their own policy with their > own priority levels for the use of email priorities, if they allow > their customers to downgrade their service level on a > per-email/per-connection basis. > If, on the other hand, the group feels that we should go for IANA > registration, that is fine with me. In that case, I would just ask > someone to provide a wording example for this, because I have never > done it yet. >=20 > A problem Dan mentions in his email to the mailing list is the problem > of authorisation. He asks the question of what will stop him from > using highest priority on all emails and says that it can be solved > within an administrative domain but probably not across them. >=20 > As I have already indicated above, I see this problem as well. >=20 > When I created the I-D, it was for a scenario of cooperating > administrative domains and thus, this problem did not present itself: > The domain administrations had agreed on a policy for the use of > priorities. >=20 > Of course, one thing preventing excessive use of high priorities is > the size limit on high-priority emails. You can not put much data in > two or four kilobyte, so you have to use lower priorities for larger > emails. >=20 > Other than that, I only have one rough idea so far how this issue > could be addressed in a general case that I would like your opinion > on: The policy could impose a frequency with which one sender may > issue emails of the higher priorities. Together with the smaller size > of high-priority emails that should guarantee at least some space for > lower priority emails >=20 >=20 >=20 > Best regards, > Michael Schmeing _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jun 14 00:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNNS-0004zO-1v; Wed, 14 Jun 2006 00:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNNQ-0004zJ-TP for ieprep@ietf.org; Wed, 14 Jun 2006 00:53:13 -0400 Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqNNP-0004nP-Fa for ieprep@ietf.org; Wed, 14 Jun 2006 00:53:12 -0400 Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1FqNNO-0002yD-BA for ieprep@ietf.org; Wed, 14 Jun 2006 06:53:10 +0200 Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1FqNNN-0005pS-00 for ; Wed, 14 Jun 2006 06:53:09 +0200 Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Wed, 14 Jun 2006 06:53:09 +0200 Date: Wed, 14 Jun 2006 06:53:09 +0200 From: Michael Schmeing To: ieprep@ietf.org Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities Message-ID: <20060614045308.GA2412@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN) User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: yes (FGAN VirusScan III) X-Scan-Signature: 33310ad9788a957f7423ac134a469312 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Tue, Jun 13, 2006 at 11:58:48AM -0400, ken carlberg wrote: > Hello Michael, Hello Ken, this is just a quick answer to a couple of points I can respond to off hand. I am going to give a more complete answer next week (I am out of office starting tommorow until Monday including). > > I would like to echo Janet's request of putting in place a > prioritization field that is more extendable so that various sets of > users could rely on different priority structures/values, but more > importantly, different associated policies. The one major headache > is that if you go down this road, I think your draft will require > some significant changes. > > [...] There seems to be a lot of interest in a more flexible priority field. While I am not at all opposed to this idea, I do not see that I have the time available to me to do it. > One minor point involves Section 4.1 You mention using the ToS field > as a means of supporting expedited transfer. Its probably best to > update that text with RFC-3168, which deprecates ToS (and precedence > fields) in favor of the Differentiated Services field. OK, that should be easy to fix. > [...] > Outside of that, it would seem desirable for your draft to at least > advocate some measures of security like S/MIME for header protection > (rfc-3851), and possibly the use of AUTH. S/MIME is strictly for the content of the email. This area has been left out of the draft because of reasons stemming from the research project I work on. In the general case it is probably a good idea to at least consider this area. As for AUTH, you are completedly right. > > Finally, in section 6.5.3, you state some specific delivery time > constraints. I'm curious as to where you came up with those numbers > -- it would probably be helpful to add some context. > > [...] Yes, it would. The times were inspired by the NATO time constraints but shortened because NATO includes the time required for some administrative actions before and after the actual transmission. (E.g. waking the commander of a unit if the message comes in the dead of the night ;-). > outside of that, its a nice document for discussion Then I have achieved a major goal of my research project already ;-) Michael -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jun 14 07:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTIF-0001D0-Ta; Wed, 14 Jun 2006 07:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTIE-0001Cu-FF for ieprep@ietf.org; Wed, 14 Jun 2006 07:12:14 -0400 Received: from athena.hosts.co.uk ([212.84.175.19] helo=hermes.hosts.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTID-0007R5-63 for ieprep@ietf.org; Wed, 14 Jun 2006 07:12:14 -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 1FqTIE-0002Eb-RJ; Wed, 14 Jun 2006 12:12:15 +0100 In-Reply-To: <20060614045308.GA2412@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> <20060614045308.GA2412@nordhorn.fkie.fgan.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities Date: Wed, 14 Jun 2006 07:12:08 -0400 To: Michael Schmeing X-Mailer: Apple Mail (2.750) X-Spam-Score: -4.4 (----) 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 > this is just a quick answer to a couple of points I can respond to off > hand. I am going to give a more complete answer next week (I am out of > office starting tommorow until Monday including). hmmmm, planning to take some time off to see the next German football match? :-) (just kidding) >> [...] >> Outside of that, it would seem desirable for your draft to at least >> advocate some measures of security like S/MIME for header protection >> (rfc-3851), and possibly the use of AUTH. > > S/MIME is strictly for the content of the email. This area has been > left out of the draft because of reasons stemming from the research > project I work on. In the general case it is probably a good idea to > at least consider this area. As for AUTH, you are completedly right. Section 3.1 of rfc-3851 has the following text... In order to protect outer, non-content related message headers (for instance, the "Subject", "To", "From" and "CC" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these headers. It is up to the receiving client to decide how to present these "inner" headers along with the unprotected "outer" headers. When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed. I was under the impression that the above left the door open for S/ MIME to protect static parts of the SMTP header. But admittedly, I'm not deeply familiar with the draft, so my apologies if I've misinterpreted things. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Jun 14 08:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUF0-0006sT-RZ; Wed, 14 Jun 2006 08:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUEz-0006pX-Tr for ieprep@ietf.org; Wed, 14 Jun 2006 08:12:57 -0400 Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUEy-0003SW-G1 for ieprep@ietf.org; Wed, 14 Jun 2006 08:12:57 -0400 Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1FqUEx-0002j6-9K; Wed, 14 Jun 2006 14:12:55 +0200 Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1FqUEw-0001RE-00; Wed, 14 Jun 2006 14:12:54 +0200 Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Wed, 14 Jun 2006 14:12:54 +0200 Date: Wed, 14 Jun 2006 14:12:54 +0200 From: Michael Schmeing To: ken carlberg Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities Message-ID: <20060614121253.GB2555@nordhorn.fkie.fgan.de> References: <20060612130135.GD9821@nordhorn.fkie.fgan.de> <20060614045308.GA2412@nordhorn.fkie.fgan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN) User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: yes (FGAN VirusScan III) X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Wed, Jun 14, 2006 at 07:12:08AM -0400, ken carlberg wrote: > [...] > >>Outside of that, it would seem desirable for your draft to at least > >>advocate some measures of security like S/MIME for header protection > >>(rfc-3851), and possibly the use of AUTH. > > > >S/MIME is strictly for the content of the email. This area has been > >left out of the draft because of reasons stemming from the research > >project I work on. In the general case it is probably a good idea to > >at least consider this area. As for AUTH, you are completedly right. > > Section 3.1 of rfc-3851 has the following text... > > In order to protect outer, non-content related message headers (for > instance, the "Subject", "To", "From" and "CC" fields), the sending > client MAY wrap a full MIME message in a message/rfc822 wrapper in > order to apply S/MIME security services to these headers. It is up > to the receiving client to decide how to present these "inner" > headers along with the unprotected "outer" headers. > > [...] > > I was under the impression that the above left the door open for S/ > MIME to protect static parts of the SMTP header. But admittedly, I'm > not deeply familiar with the draft, so my apologies if I've > misinterpreted things. To me, this appears rather to be a problem of different definitions of the term content than a misinterpretation. I meant content as in "message content" that is defined in Sec. 2.3.9 of RFC 2821 (SMTP) as "the material transmitted after the DATA command is accepted and before the end of data indication is transmitted. Message content includes message headers and the ... message body." In this definition the email header is part of the content. As such it may be secured using S/MIME but still is outside the (current) scope of the draft. S/MIME obviously has a different definition of the term "content" that only includes (parts of?) what is called "message body" but excludes at least some header fields (probably those defined in RFCs 2821/2822). Greetings, Michael -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Sat Jun 17 20:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrlLg-00014p-8o; Sat, 17 Jun 2006 20:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrlLe-00014k-FI for ieprep@ietf.org; Sat, 17 Jun 2006 20:41:06 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrlLd-0002zt-VP for ieprep@ietf.org; Sat, 17 Jun 2006 20:41:06 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5I0f3ho028056; Sat, 17 Jun 2006 19:41:03 -0500 (CDT) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.3]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jun 2006 19:41:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 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] Another version of a potential IEPREP charter Date: Sat, 17 Jun 2006 19:41:01 -0500 Message-ID: <7A5EF92F6D86BD419418FFBD69E882B654D124@ILEXC1U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] Another version of a potential IEPREP charter Thread-Index: AcaOPbBA39jgZ6UgR1WELGL7/BzMigEMUdGQ From: "GOLDMAN, STUART O \(STUART\)" To: "King, Kimberly S." , X-OriginalArrivalTime: 18 Jun 2006 00:41:02.0932 (UTC) FILETIME=[E054D940:01C6926F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 Kimberly, Kimberly, Given the vital importance of emergency communications during disasters as described below, it certainly seems that the IEPREP group is still needed. I have no improvements to the draft charter you have proposed. Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com]=20 Sent: Monday, June 12, 2006 9:30 AM To: ieprep@ietf.org Subject: [Ieprep] Another version of a potential IEPREP charter We were asked to tighten up the potential new charter. Here is a start. Comments? ________________________ =20 =20 =20 Internet Emergency Preparedness (ieprep) Charter =20 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. =20 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. =20 The IEPREP WG will address proactive measures to congestion and recovery from various outages using three perspectives: =20 1. A commercial (i.e., or public) telecommunications infrastructure =20 2. An enterprise or governmental/military telecommunications infrastructure that retains sole administration of its own network resources =20 3. A governmental/military telecommunications infrastructure that combines private resources and leverages public infrastructure.=20 =20 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:=20 =20 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. =20 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. =20 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. =20 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. =20 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. =20 =20 Goals and Milestones:=20 =20 Done Submit initial I-D of Requirements=20 =20 Done Submit initial I-D of Framework =20 Done Submit initial I-D of Recommendations BCP=20 =20 Done Produce an Requirements I-D to IESG for publication as an Informational RFC=20 =20 Done Submit Framework I-D to IESG for publication as an Informational RFC=20 =20 Aug 06 Submit an initial I-D of Requirements of Government/Military Networks for Precedence and Preemption =20 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 =20 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. =20 Nov 06 Submit final I-D of Requirements of Government/Military Networks for Precedence and Preemption to IESG for publication as an Informational RFC =20 NOV 06 Submit final I-D of ETS Terminology to IESG for publication as an Informational RFC. =20 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. =20 Feb 07 Submit an initial I-D of Mechanisms for Precedence and Preemption to be used by Government/Military Networks =20 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 =20 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). =20 =20 =20 _______________________________________________ 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 Jun 23 20:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftw8A-0001IX-EZ; Fri, 23 Jun 2006 20:36:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftw89-0001F0-Mo for ieprep@ietf.org; Fri, 23 Jun 2006 20:36:09 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ftw89-0003BW-6X for ieprep@ietf.org; Fri, 23 Jun 2006 20:36:09 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1151109367!12890326!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30019 invoked from network); 24 Jun 2006 00:36:07 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-120.messagelabs.com with SMTP; 24 Jun 2006 00:36:07 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F0033EF37; Fri, 23 Jun 2006 20:36:07 -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] (Forwarded) alternate version of revised IEPREP charter Date: Fri, 23 Jun 2006 19:36:06 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C90D@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] (Forwarded) alternate version of revised IEPREP charter Thread-Index: AcaPEf1vJ3bahjRQRKOl2/4d7g0FlAIE41Ow X-Message-Flag: Follow up From: "Dolly, Martin C, ALABS" To: "Janet P Gunn" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: "Taylor, Carollyn D CIV NCS NC2" , stephen.perschau@dhs.gov 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 Hello, I support this charter, and being there has not been ay other views, I assume you all agree as well. (ass/u/me) Kimberly: what is your view as chair??? Peace, Martin -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Tuesday, June 13, 2006 1:37 PM To: ieprep@ietf.org Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov Subject: [Ieprep] (Forwarded) alternate version of revised IEPREP charter I have been asked to send this to the IEPREP list on behalf of Carol-Lyn Taylor and Stephen Perschau (both of NCS). 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. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------- ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM ----- > Sent on behalf of Stephen Perschau: > > Attached is a version of the proposed draft new charter that I would > like to see discussed. It is different from the one sent by Dr. > King. This version of the proposed draft charter focuses on DoD > aspects. MLPP is not an intrinsic aspect of an ETS although it can > be used where permitted. MLPP is used on a daily basis by DoD in > their enterprise network and the charter should reflect that fact. > Stephen Perschau > ********************************************************************* > MTW (MLPP That Works) Formally (ieprep) Charter > > Description of Working Group: Effective telecommunications > capabilities in enterprise networks (private commercial or > government/military networks) are necessary for normal day-to-day > operations. These enterprise capabilities can also be used to > facilitate response and recovery operations for emergency events > including natural disasters (e.g., hurricanes, floods, earthquakes) > and those created by man (e.g., terrorist attacks, combat situations > or wartime events). > > The WG will address proactive measures to deal with emergency events > from the following perspectives: > > 1. A government/military telecommunications network that retains > sole administration 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. > The following apply: > 1. 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' > 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 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. > > 2. 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 > differing security levels, etc. that should be described before > mechanisms are proposed. The WG will document the context for > implementing solutions. In addition, solutions must be developed > when appropriate. > > 3. While voice was the driving application in the past, preferential > treatment will need to be applied to all applications used in > response and recovery operations. Preferential treatment must be > applied to real-time (e.g., voice) and non-real-time applications > (e.g., Text messaging, SMS) that share the same network. The WG will > document the preferential treatment mechanisms that are appropriate > for any essential communications. > > In the IETF, considerations for treatment and security of > communications for response and recovery operations 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. The WG will cooperate closely with these groups > and with those outside of the IETF such as ITU-T study groups. In > addition, the WG 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, the WG 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, the WG will prepare requirements and > discuss the extension of that protocol/mechanism or > protocols/mechanisms within the WG. > > Goals and Milestones: > > Aug 06 Submit an initial I-D of Requirements of Government/Military > Networks for Precedence and Preemption > > 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. > Jan 07 Submit 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). > > Classification: UNCLASSIFIED > Caveats: NONE > > Classification: UNCLASSIFIED > Caveats: NONE _______________________________________________ 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 Sun Jun 25 12:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXEe-0003IH-6E; Sun, 25 Jun 2006 12:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXEd-0003IC-51 for ieprep@ietf.org; Sun, 25 Jun 2006 12:13:19 -0400 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXEb-0001GI-Mt for ieprep@ietf.org; Sun, 25 Jun 2006 12:13:19 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k5PGDEs06795; Sun, 25 Jun 2006 12:13:14 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006062512131202165 ; Sun, 25 Jun 2006 12:13:12 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jun 2006 12:13:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] (Forwarded) alternate version of revised IEPREP charter Date: Sun, 25 Jun 2006 12:13:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] (Forwarded) alternate version of revised IEPREP charter Thread-Index: AcaPEf1vJ3bahjRQRKOl2/4d7g0FlAIE41OwAFMRQTA= From: "Sandesara, Niranjan B" To: "Dolly, Martin C, ALABS" , "Janet P Gunn" , X-OriginalArrivalTime: 25 Jun 2006 16:13:13.0009 (UTC) FILETIME=[42259210:01C69872] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: "Taylor, Carollyn D CIV NCS NC2" , stephen.perschau@dhs.gov 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! I support the alternate charter distributed by Janet on behalf of the NCS. Text of that charter clearly focuses on the milestones and activities the group intends to undertake. Niranjan Sandesara=20 -----Original Message----- From: Dolly, Martin C, ALABS [mailto:mdolly@att.com]=20 Sent: Friday, June 23, 2006 8:36 PM To: Janet P Gunn; ieprep@ietf.org Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter Hello, I support this charter, and being there has not been ay other views, I assume you all agree as well. (ass/u/me) Kimberly: what is your view as chair??? Peace, Martin -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Tuesday, June 13, 2006 1:37 PM To: ieprep@ietf.org Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov Subject: [Ieprep] (Forwarded) alternate version of revised IEPREP charter I have been asked to send this to the IEPREP list on behalf of Carol-Lyn Taylor and Stephen Perschau (both of NCS). 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. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------- ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM ----- > Sent on behalf of Stephen Perschau: > > Attached is a version of the proposed draft new charter that I would > like to see discussed. It is different from the one sent by Dr. > King. This version of the proposed draft charter focuses on DoD > aspects. MLPP is not an intrinsic aspect of an ETS although it can > be used where permitted. MLPP is used on a daily basis by DoD in > their enterprise network and the charter should reflect that fact. > Stephen Perschau > ********************************************************************* > MTW (MLPP That Works) Formally (ieprep) Charter > > Description of Working Group: Effective telecommunications > capabilities in enterprise networks (private commercial or > government/military networks) are necessary for normal day-to-day > operations. These enterprise capabilities can also be used to > facilitate response and recovery operations for emergency events > including natural disasters (e.g., hurricanes, floods, earthquakes) > and those created by man (e.g., terrorist attacks, combat situations > or wartime events). > > The WG will address proactive measures to deal with emergency events > from the following perspectives: > > 1. A government/military telecommunications network that retains > sole administration 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. > The following apply: > 1. 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' > 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 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. > > 2. 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 > differing security levels, etc. that should be described before > mechanisms are proposed. The WG will document the context for > implementing solutions. In addition, solutions must be developed > when appropriate. > > 3. While voice was the driving application in the past, preferential > treatment will need to be applied to all applications used in > response and recovery operations. Preferential treatment must be > applied to real-time (e.g., voice) and non-real-time applications > (e.g., Text messaging, SMS) that share the same network. The WG will > document the preferential treatment mechanisms that are appropriate > for any essential communications. > > In the IETF, considerations for treatment and security of > communications for response and recovery operations 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. The WG will cooperate closely with these groups > and with those outside of the IETF such as ITU-T study groups. In > addition, the WG 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, the WG 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, the WG will prepare requirements and > discuss the extension of that protocol/mechanism or > protocols/mechanisms within the WG. > > Goals and Milestones: > > Aug 06 Submit an initial I-D of Requirements of Government/Military > Networks for Precedence and Preemption > > 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. > Jan 07 Submit 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). > > Classification: UNCLASSIFIED > Caveats: NONE > > Classification: UNCLASSIFIED > Caveats: NONE _______________________________________________ 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 Jun 26 09:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurNJ-0000LN-8N; Mon, 26 Jun 2006 09:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurNH-0000LD-9Z for ieprep@ietf.org; Mon, 26 Jun 2006 09:43:35 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurNG-0000tm-Oe for ieprep@ietf.org; Mon, 26 Jun 2006 09:43:35 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 26 Jun 2006 09:43:24 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006062609432127269 ; Mon, 26 Jun 2006 09:43:22 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jun 2006 09:43:21 -0400 Message-Id: <702ADCB87C5EF340B1D7A597A9DFF1DA01426E9F@0015-its-exmb02.us.saic.com> From: "King, Kimberly S." To: "Dolly, Martin C, ALABS" , Janet P Gunn , ieprep@ietf.org Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP char ter Date: Mon, 26 Jun 2006 09:43:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: "Taylor, Carollyn D CIV NCS NC2" , stephen.perschau@dhs.gov 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 Hello Martin, I am pleased that folks are expressing support for the milestones and activities presented in the alternate version of the charter as they coincide with the version of the charter that I sent out. The only substantive change of the potentially revised charter (sent out by Janet on behalf of Steve) is a name change of the working group from IEPREP to MTW (MLPP That Works). I think there is little chance of the IESG supporting such a name change. Thus if it is the work and the activities are what is important, then it makes sense to focus on the version that I posted on June 12. Namely: Internet Emergency Preparedness (ieprep) Charter 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). -----Original Message----- From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of Dolly, Martin C, ALABS Sent: Friday, June 23, 2006 8:36 PM To: Janet P Gunn; ieprep@ietf.org Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter Hello, I support this charter, and being there has not been ay other views, I assume you all agree as well. (ass/u/me) Kimberly: what is your view as chair??? Peace, Martin -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Tuesday, June 13, 2006 1:37 PM To: ieprep@ietf.org Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov Subject: [Ieprep] (Forwarded) alternate version of revised IEPREP charter I have been asked to send this to the IEPREP list on behalf of Carol-Lyn Taylor and Stephen Perschau (both of NCS). 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. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------- ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM ----- > Sent on behalf of Stephen Perschau: > > Attached is a version of the proposed draft new charter that I would > like to see discussed. It is different from the one sent by Dr. > King. This version of the proposed draft charter focuses on DoD > aspects. MLPP is not an intrinsic aspect of an ETS although it can > be used where permitted. MLPP is used on a daily basis by DoD in > their enterprise network and the charter should reflect that fact. > Stephen Perschau > ********************************************************************* > MTW (MLPP That Works) Formally (ieprep) Charter > > Description of Working Group: Effective telecommunications > capabilities in enterprise networks (private commercial or > government/military networks) are necessary for normal day-to-day > operations. These enterprise capabilities can also be used to > facilitate response and recovery operations for emergency events > including natural disasters (e.g., hurricanes, floods, earthquakes) > and those created by man (e.g., terrorist attacks, combat situations > or wartime events). > > The WG will address proactive measures to deal with emergency events > from the following perspectives: > > 1. A government/military telecommunications network that retains > sole administration 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. > The following apply: > 1. 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' > 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 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. > > 2. 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 > differing security levels, etc. that should be described before > mechanisms are proposed. The WG will document the context for > implementing solutions. In addition, solutions must be developed > when appropriate. > > 3. While voice was the driving application in the past, preferential > treatment will need to be applied to all applications used in > response and recovery operations. Preferential treatment must be > applied to real-time (e.g., voice) and non-real-time applications > (e.g., Text messaging, SMS) that share the same network. The WG will > document the preferential treatment mechanisms that are appropriate > for any essential communications. > > In the IETF, considerations for treatment and security of > communications for response and recovery operations 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. The WG will cooperate closely with these groups > and with those outside of the IETF such as ITU-T study groups. In > addition, the WG 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, the WG 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, the WG will prepare requirements and > discuss the extension of that protocol/mechanism or > protocols/mechanisms within the WG. > > Goals and Milestones: > > Aug 06 Submit an initial I-D of Requirements of Government/Military > Networks for Precedence and Preemption > > 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. > Jan 07 Submit 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). > > Classification: UNCLASSIFIED > Caveats: NONE > > Classification: UNCLASSIFIED > Caveats: NONE _______________________________________________ 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 Jun 26 10:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus26-0002lE-PQ; Mon, 26 Jun 2006 10:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus25-0002iv-Fb for ieprep@ietf.org; Mon, 26 Jun 2006 10:25:45 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fus1y-0004SP-25 for ieprep@ietf.org; Mon, 26 Jun 2006 10:25:45 -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 k5QEPbi4007669 for ; Mon, 26 Jun 2006 10:25:37 -0400 (EDT) In-Reply-To: <702ADCB87C5EF340B1D7A597A9DFF1DA01426E9F@0015-its-exmb02.us.saic.com> Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP charter To: "King, Kimberly S." , ieprep@ietf.org X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Mon, 26 Jun 2006 10:25:34 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/26/2006 10:24:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 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 I agree. 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "King, Kimberly S." wrote on 06/26/2006 09:43:08 AM: > Hello Martin, > > I am pleased that folks are expressing support for the milestones and > activities presented in the alternate version of the charter as they > coincide with the version of the charter that I sent out. > > The only substantive change of the potentially revised charter (sent out by > Janet on behalf of Steve) is a name change of the working group from IEPREP > to MTW (MLPP That Works). I think there is little chance of the IESG > supporting such a name change. Thus if it is the work and the activities > are what is important, then it makes sense to focus on the version that I > posted on June 12. > > Namely: > > > Internet Emergency Preparedness (ieprep) Charter > > > > 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). > > > > -----Original Message----- > From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of > Dolly, Martin C, ALABS > Sent: Friday, June 23, 2006 8:36 PM > To: Janet P Gunn; ieprep@ietf.org > Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov > Subject: RE: [Ieprep] (Forwarded) alternate version of revised IEPREP > charter > > Hello, > > I support this charter, and being there has not been ay other views, I > assume you all agree as well. (ass/u/me) > > Kimberly: what is your view as chair??? > > Peace, > > Martin > > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: Tuesday, June 13, 2006 1:37 PM > To: ieprep@ietf.org > Cc: Taylor, Carollyn D CIV NCS NC2; stephen.perschau@dhs.gov > Subject: [Ieprep] (Forwarded) alternate version of revised IEPREP > charter > > > > > > I have been asked to send this to the IEPREP list on behalf of Carol-Lyn > Taylor and Stephen Perschau (both of NCS). > > 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. > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > -------------------------------- > > > ----- Forwarded by Janet P Gunn/FED/CSC on 06/13/2006 01:30 PM ----- > > > > Sent on behalf of Stephen Perschau: > > > > Attached is a version of the proposed draft new charter that I would > > like to see discussed. It is different from the one sent by Dr. > > King. This version of the proposed draft charter focuses on DoD > > aspects. MLPP is not an intrinsic aspect of an ETS although it can > > be used where permitted. MLPP is used on a daily basis by DoD in > > their enterprise network and the charter should reflect that fact. > > Stephen Perschau > > ********************************************************************* > > MTW (MLPP That Works) Formally (ieprep) Charter > > > > Description of Working Group: Effective telecommunications > > capabilities in enterprise networks (private commercial or > > government/military networks) are necessary for normal day-to-day > > operations. These enterprise capabilities can also be used to > > facilitate response and recovery operations for emergency events > > including natural disasters (e.g., hurricanes, floods, earthquakes) > > and those created by man (e.g., terrorist attacks, combat situations > > or wartime events). > > > > The WG will address proactive measures to deal with emergency events > > from the following perspectives: > > > > 1. A government/military telecommunications network that retains > > sole administration 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. > > The following apply: > > 1. 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' > > 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 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. > > > > 2. 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 > > differing security levels, etc. that should be described before > > mechanisms are proposed. The WG will document the context for > > implementing solutions. In addition, solutions must be developed > > when appropriate. > > > > 3. While voice was the driving application in the past, preferential > > treatment will need to be applied to all applications used in > > response and recovery operations. Preferential treatment must be > > applied to real-time (e.g., voice) and non-real-time applications > > (e.g., Text messaging, SMS) that share the same network. The WG will > > document the preferential treatment mechanisms that are appropriate > > for any essential communications. > > > > In the IETF, considerations for treatment and security of > > communications for response and recovery operations 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. The WG will cooperate closely with these groups > > and with those outside of the IETF such as ITU-T study groups. In > > addition, the WG 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, the WG 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, the WG will prepare requirements and > > discuss the extension of that protocol/mechanism or > > protocols/mechanisms within the WG. > > > > Goals and Milestones: > > > > Aug 06 Submit an initial I-D of Requirements of Government/Military > > Networks for Precedence and Preemption > > > > 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. > > Jan 07 Submit 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). > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > _______________________________________________ > 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