From mailman-bounces@ietf.org Fri Oct 1 06:03:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12690 for ; Fri, 1 Oct 2004 06:03:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKOL-0003Jv-QY for ieprep-web-archive@ietf.org; Fri, 01 Oct 2004 06:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJY3-0006Ts-5e for ieprep-web-archive@ietf.org; Fri, 01 Oct 2004 05:17:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ieprep-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:03:48 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-web-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org itzoun https://www1.ietf.org/mailman/options/ieprep/ieprep-web-archive%40ietf.org From ieprep-bounces@ietf.org Tue Oct 12 08:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15919 for ; Tue, 12 Oct 2004 08:43:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMBA-0004Ky-H6 for ieprep-web-archive@ietf.org; Tue, 12 Oct 2004 08:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHLvG-0002oM-Fi; Tue, 12 Oct 2004 08:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHLqE-0001Om-RP for ieprep@megatron.ietf.org; Tue, 12 Oct 2004 08:33:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14887 for ; Tue, 12 Oct 2004 08:33:21 -0400 (EDT) From: steve.norreys@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHM0y-00046E-2s for ieprep@ietf.org; Tue, 12 Oct 2004 08:44:28 -0400 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 12 Oct 2004 13:33:46 +0100 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 13:33:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Oct 2004 13:33:45 +0100 Message-ID: <9D598A34672DF24F89FF4F851A4161950D2AF1CD@i2km08-ukbr.domain1.systemhost.net> Thread-Topic: Meaning of Single Administrative Domain Thread-Index: AcSwV5PSFWKJg6/AQ0O5E4j+QnM62A== To: X-OriginalArrivalTime: 12 Oct 2004 12:33:45.0838 (UTC) FILETIME=[B75FF8E0:01C4B057] X-Spam-Score: 1.0 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [Ieprep] Meaning of Single Administrative Domain 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable All Perhaps someone out there can help me as I am having some difficulty in defining the exact meaning of a single administrative domain that is part of the last call for "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain". According to draft-ietf-ieprep-domain-req-02.txt section 1 the explanation of the Administrative Domain: is "The collection of resources under the control of a single administrative authority. This authority establishes the design and operation of a set of resources (i.e., the network)."=20 However further on in the document in section 4.2 in the explanation of the relationship to the work ongoing in the ITU-T this statement is made: "However, to provide a bridge of understanding, the reader can assume that ETS within the IETF is synonymous with TDR in the ITU -- each involving authorized use of a service that attempts to compensate for stressed conditions of resources." These two statements are in my mind conflicting. In the recent ITU-T PCP meeting one of the definitions of TDR is to do with international communications to and from the disaster area and local communications at the disaster area. This is not a single network on the contrary it is a requirement for cooperation of many networks especially international networks. I may have misunderstood the point here and would grateful if someone could put me on the correct path. Regards Steve Norreys =20 Signalling and Protocols Tel: +441277323220 email steve.norreys@bt.com British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.=20 Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Oct 12 10:21:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22782 for ; Tue, 12 Oct 2004 10:21:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNaL-0005sH-7v for ieprep-web-archive@ietf.org; Tue, 12 Oct 2004 10:25:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CHMzM-0003Z2-F9 for ieprep-web-archive@ietf.org; Tue, 12 Oct 2004 09:46:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMh5-0008KH-6W; Tue, 12 Oct 2004 09:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMYC-000501-I1 for ieprep@megatron.ietf.org; Tue, 12 Oct 2004 09:18:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18614 for ; Tue, 12 Oct 2004 09:18:46 -0400 (EDT) Message-Id: <200410121318.JAA18614@ietf.org> Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHMim-0004xR-5K for ieprep@ietf.org; Tue, 12 Oct 2004 09:29:54 -0400 Received: (qmail 32330 invoked from network); 12 Oct 2004 13:18:02 -0000 Received: from pcp08649708pcs.towson01.md.comcast.net (HELO albers) (69.137.47.20) by phobos.simply.net with SMTP; 12 Oct 2004 13:18:02 -0000 From: "Ken Carlberg" To: , Subject: RE: [Ieprep] Meaning of Single Administrative Domain Date: Tue, 12 Oct 2004 09:17:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSwV5PSFWKJg6/AQ0O5E4j+QnM62AAA2eGQ In-Reply-To: <9D598A34672DF24F89FF4F851A4161950D2AF1CD@i2km08-ukbr.domain1.systemhost.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit In the Abstract, I state the following: "This document is an extension of the General Requirements of [rfc3689] and focuses on a more specific set of administrative constraints and scope." And the Introduction, I state that "we constrain our scenario to the resources within a single domain". The intent of the document is to look at the subject of ETS within a single domain. It does not mean that ETS == single domain, or that it only operates within a single domain. Further, the text in 4.2 is meant to state a correlation between ITU's use of TDR and IETF's use of ETS. I thought it would be helpful for readers initial exposure to both terms. But again, section 4.2 is not meant to imply that ETS is applied exclusively to a single domain. The solution is to either restate in section 4.2 what I said in the introduction, or simply rip out 4.2. If the ITU's position on TDR is fluid, then I'll favor option 2. -ken ps, on a sidenote, I'm on travel to London later today, so I'll be slow in responding in the next day or so. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Oct 12 10:58:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27533 for ; Tue, 12 Oct 2004 10:58:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOHN-000745-Ve for ieprep-web-archive@ietf.org; Tue, 12 Oct 2004 11:09:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHO25-0000he-Bk; Tue, 12 Oct 2004 10:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNmj-0004Yv-Uj for ieprep@megatron.ietf.org; Tue, 12 Oct 2004 10:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25050 for ; Tue, 12 Oct 2004 10:37:52 -0400 (EDT) From: steve.norreys@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNxU-0006bd-4u for ieprep@ietf.org; Tue, 12 Oct 2004 10:49:01 -0400 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 12 Oct 2004 15:34:21 +0100 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 15:34:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Meaning of Single Administrative Domain Date: Tue, 12 Oct 2004 15:34:16 +0100 Message-ID: <9D598A34672DF24F89FF4F851A4161950D2AF457@i2km08-ukbr.domain1.systemhost.net> Thread-Topic: [Ieprep] Meaning of Single Administrative Domain Thread-Index: AcSwV5PSFWKJg6/AQ0O5E4j+QnM62AAA2eGQAAHGibA= To: , X-OriginalArrivalTime: 12 Oct 2004 14:34:17.0411 (UTC) FILETIME=[8DBA7130:01C4B068] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Ken I would agree it was also my understanding that ETS =3D/=3D single = domain but was an indication of how an single administrative domain (network) control its resources for a ETS session. So to this end I think that the text to correlate the work here and the ITU-T does not clarify but confuses the situation. So I would agree that the text in section 4.2 is removed. As far as the ITU-T is concerned the Partnership Coordination Panel (PCP) for TDR is supposed to meet in November but I haven't seen a notice or received an invite as yet. So your guess is as good as mine concerning the progress of TDR/ETS work in the ITU-T. Regards Steve -----Original Message----- From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of Ken Carlberg Sent: 12 October 2004 14:18 To: Norreys,SE,Steve,XJG4 R; ieprep@ietf.org Subject: RE: [Ieprep] Meaning of Single Administrative Domain In the Abstract, I state the following: "This document is an extension of the General Requirements of [rfc3689] and focuses on a more specific set of administrative constraints and scope." =20 And the Introduction, I state that "we constrain our scenario to the resources within a single domain". The intent of the document is to look at the subject of ETS within a single domain. It does not mean that ETS =3D=3D single domain, or that = it only operates within a single domain. Further, the text in 4.2 is meant to state a correlation between ITU's use of TDR and IETF's use of ETS. I thought it would be helpful for readers initial exposure to both terms. But again, section 4.2 is not meant to imply that ETS is applied exclusively to a single domain. The solution is to either restate in section 4.2 what I said in the introduction, or simply rip out 4.2. If the ITU's position on TDR is fluid, then I'll favor option 2. -ken ps, on a sidenote, I'm on travel to London later today, so I'll be slow in responding in the next day or so. _______________________________________________ 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 Oct 12 14:09:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15399 for ; Tue, 12 Oct 2004 14:09:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRGA-0003ni-84 for ieprep-web-archive@ietf.org; Tue, 12 Oct 2004 14:20:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQxn-0007PE-7Z; Tue, 12 Oct 2004 14:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQq7-0004rZ-5V for ieprep@megatron.ietf.org; Tue, 12 Oct 2004 13:53:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14046 for ; Tue, 12 Oct 2004 13:53:34 -0400 (EDT) Received: from ellis.ad.nps.navy.mil ([131.120.18.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHR0t-0003QJ-Ls for ieprep@ietf.org; Tue, 12 Oct 2004 14:04:44 -0400 Received: from [131.120.179.249] ([131.120.179.249]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 10:53:29 -0700 Subject: Re: [Ieprep] Meaning of Single Administrative Domain From: Rex Buddenberg To: steve.norreys@bt.com In-Reply-To: <9D598A34672DF24F89FF4F851A4161950D2AF1CD@i2km08-ukbr.domain1.systemhost.net> References: <9D598A34672DF24F89FF4F851A4161950D2AF1CD@i2km08-ukbr.domain1.systemhost.net> Content-Type: text/plain Message-Id: <1097603609.1779.64.camel@antony> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 12 Oct 2004 10:53:29 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2004 17:53:29.0436 (UTC) FILETIME=[61B0B9C0:01C4B084] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Steve, This is pretty important both to the organization and the technology. Ken's pretty much on target. The definition you repeated is one that matches up administrative control and autonomous systems and is generally used in IETF. When the Internet (then ARPANet) started tiering, the notion of Autonomous Systems was born and routers got a differentiation with exterior and interior gateway protocols. (Hope this isn't too pedantic a review). Within an AS, we run an interior protocol (such as OSPF) and all routers have identical knowledge of the network topology (assuming the network is converged). Administratively, this can only really happen if we have a single administrative control. This comprehensive knowledge of which routers can directly talk with which is confined to the AS -- the outside world (other admin domains) don't know. Rather they only know where the gateways into this AS are. These gateways (border routers) say 'send traffic to this AS to me and I'll take care of it'. Exterior gateway protocols (BGP4) implement this approach. This handles the interface between administrative domains ... and ASs. Why's this important in emergency services? Case 1 might be where the fire department has a network in a community to control its assets and the police department has another, different network. Two ASs. And I've certainly seen communities where this kind of insularity exists. The upsides in this partitioning have to do with security (enclaving). The downsides include poorer Ao for a fixed amount of infrastructure, greater difficulty in controlling QoS (assuming inadequate overprovisioning that necessitates it) and flexibility to meet changing situations. Case 2 might be where the city administration runs the entire network as a single AS. The upsides and downsides noted above essentially evert. But one has to draw a line somewhere -- it doesn't make sense for a community to attempt to run it's network as the same AS as a national emergency service network (e.g. national level police force or coast guard). And it may or may not make sense for the emergency services network to be in the same AS as the k12 schools. The problem Ken is trying to frame comes from some past discussion on this board where trying to pass diff-serv (DS byte) information across border routers is deemed as: 1) necessary to make diff-serv work end-to-end. A good share of the discussion is whether that's necessary. 2) leaving a gaping security hole open. A Bad Guy can flood a network with high priority traffic and thereby impose a denial of service attack. (All the practicing ISPs lined up here -- they all zero out the DS byte to close off the DOS vector). That help any? On Tue, 2004-10-12 at 05:33, steve.norreys@bt.com wrote: > All > > Perhaps someone out there can help me as I am having some difficulty in > defining the exact meaning of a single administrative domain that is > part of the last call for "Emergency Telecommunications Services (ETS) > Requirements for a Single Administrative Domain". > > According to draft-ietf-ieprep-domain-req-02.txt section 1 the > explanation of the Administrative Domain: is "The collection of > resources under the control of a single administrative authority. This > authority establishes the design and operation of a set of resources > (i.e., the network)." > > However further on in the document in section 4.2 in the explanation of > the relationship to the work ongoing in the ITU-T this statement is > made: "However, to provide a bridge of > understanding, the reader can assume that ETS within the IETF is > synonymous with TDR in the ITU -- each involving authorized use of a > service that attempts to compensate for stressed conditions of > resources." > > These two statements are in my mind conflicting. In the recent ITU-T PCP > meeting one of the definitions of TDR is to do with international > communications to and from the disaster area and local communications at > the disaster area. This is not a single network on the contrary it is a > requirement for cooperation of many networks especially international > networks. > > I may have misunderstood the point here and would grateful if someone > could put me on the correct path. > > > Regards > > Steve Norreys > Signalling and Protocols > Tel: +441277323220 > email steve.norreys@bt.com > > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > This electronic message contains information from British > Telecommunications plc which may be privileged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message > in error, please notify us by telephone or email (to the numbers or > address above) immediately. > Activity and use of the British Telecommunications plc E-mail system is > monitored to secure its effective operation and for other lawful > business purposes. Communications using this system will also be > monitored and may be recorded to secure effective operation and for > other lawful business purposes. > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Oct 15 10:27:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05875 for ; Fri, 15 Oct 2004 10:27:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITFC-0000PX-Lu for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 10:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIStW-0003SQ-M9; Fri, 15 Oct 2004 10:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISrg-00034O-Cs for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 10:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03813 for ; Fri, 15 Oct 2004 10:15:25 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIT33-0008V7-O1 for ieprep@ietf.org; Fri, 15 Oct 2004 10:27:14 -0400 Received: from mcl-its-ieg02.mail.saic.com by mclmx2.mail.saic.com for ieprep@ietf.org; Fri, 15 Oct 2004 10:15:15 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg02.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004101510165424961 for ; Fri, 15 Oct 2004 10:16:54 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <4W70JCKQ>; Fri, 15 Oct 2004 10:15:15 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Fri, 15 Oct 2004 10:15:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ieprep] IDs to consider 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 draft-baker-tsvwg-mlef-concerns-02.txt draft-baker-tsvwg-mlpp-that-works-02.txt The above IDs are not quite in our charter but they are relevant to the ieprep mission - we would like people on the list to review and comment on them with a view to recommending to the IESG that they be published as informational RFCs Scott & Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Oct 15 11:45:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14867 for ; Fri, 15 Oct 2004 11:45:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIURs-0002bi-4U for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 11:56:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUBl-0007AI-8E; Fri, 15 Oct 2004 11:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITwm-0004I7-1V for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 11:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12554 for ; Fri, 15 Oct 2004 11:24:45 -0400 (EDT) Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIU8A-0001xg-BP for ieprep@ietf.org; Fri, 15 Oct 2004 11:36:34 -0400 Received: from Steve (ha30s122.d.shentel.net [204.111.23.122]) by seahorse.shentel.net (8.12.11/8.12.11) with SMTP id i9FFODbk006174; Fri, 15 Oct 2004 11:24:13 -0400 From: "Steve Silverman" To: "King, Kimberly S." , "Ieprep \(E-mail\)" Subject: RE: [Ieprep] IDs to consider Date: Fri, 15 Oct 2004 11:24:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit I would like to ask why this is being considered in the IEPREP WG when the drafts were always submitted to the TSVWG and have been discussed there. I don't think there was any notice given to the tsvwg that this topic was being moved here. (Then again, when Fred submitted these drafts to that WG on work that had been submitted here, he never announced on this list that he was moving the topic to that forum. Despite the fact that he was attacking my draft, he never notified me that he was doing so. ) As to the draft itself, it is still attacks MLEF (the title throughout the document after the first page is "MLEF Considered Harmful") on the assumption that no CAC is being used. As has been stated in recent MLEF drafts, in discussion in TSVWG, and in private conversations with both Fred Baker and James Polk, if the CAC works as advertised, MLEF will have no effect but if for any reason the CAC is unable to avoid congestion, MLEF will ensure that only lower priority packets are dropped. Some of us have doubts as to how well a CAC can work. If a 100% effective CAC can be implemented and demonstrated, MLEF will be unnecessary and a tiny amount of code wasted. But if congestion does arise, the high priority call packets will get thru. The dropping of packets due to congestion is not the fault of MLEF, it is necessitated by the congestion. All MLEF is doing is deciding WHICH packets are to be dropped. It does not add significant processing or introduce any delay to the packets. The DOD can not deploy VoIP without a prioritization mechanism. MLEF is such a prioritization mechanism. Steve Silverman > -----Original Message----- > From: ieprep-bounces@ietf.org > [mailto:ieprep-bounces@ietf.org]On Behalf > Of King, Kimberly S. > Sent: Friday, October 15, 2004 10:15 AM > To: Ieprep (E-mail) > Subject: [Ieprep] IDs to consider > > > > > draft-baker-tsvwg-mlef-concerns-02.txt > draft-baker-tsvwg-mlpp-that-works-02.txt > > The above IDs are not quite in our charter but they are > relevant to the ieprep mission - we would like people > on the list to review and comment on them with a view > to recommending to the IESG that they > be published as informational RFCs > > Scott & Kimberly > > _______________________________________________ > 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 Oct 15 12:21:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17249 for ; Fri, 15 Oct 2004 12:21:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIV0v-0003PV-Fv for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 12:33:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUZZ-0004Xe-Id; Fri, 15 Oct 2004 12:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUT5-0002xm-Rg for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 11:58:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15740 for ; Fri, 15 Oct 2004 11:58:09 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUeT-0002vH-JZ for ieprep@ietf.org; Fri, 15 Oct 2004 12:09:58 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 15 Oct 2004 11:58:01 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004101511580111426 ; Fri, 15 Oct 2004 11:58:01 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <4YVYHQPG>; Fri, 15 Oct 2004 11:58:01 -0400 Message-Id: From: "King, Kimberly S." To: "'Steve Silverman'" , "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IDs to consider Date: Fri, 15 Oct 2004 11:57:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Steve, The drafts draft-baker-tsvwg-mlef-concerns-02.txt draft-baker-tsvwg-mlpp-that-works-02.txt are not moved into IEPREP but we want to expose them to the IEPREP audience, take comments and then summarize them for TSVWG. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Oct 15 17:17:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22483 for ; Fri, 15 Oct 2004 17:17:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZdi-0005K1-9f for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 17:29:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYTG-0000WU-Ai; Fri, 15 Oct 2004 16:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYEE-0006qx-H3 for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 15:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05148 for ; Fri, 15 Oct 2004 15:59:04 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYPe-0008Tk-C7 for ieprep@ietf.org; Fri, 15 Oct 2004 16:10:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2004 13:05:21 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9FJwWk2008271; Fri, 15 Oct 2004 12:58:32 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA21693; Fri, 15 Oct 2004 12:58:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20041015145655.051b7c50@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Oct 2004 14:58:37 -0500 To: "King, Kimberly S." , "Ieprep (E-mail)" From: "James M. Polk" Subject: Re: [Ieprep] IDs to consider In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 10:15 AM 10/15/2004 -0400, King, Kimberly S. wrote: > draft-baker-tsvwg-mlef-concerns-02.txt > draft-baker-tsvwg-mlpp-that-works-02.txt > > recommending to the IESG that they >be published as informational RFCs Informational... Where did that classification come from? >Scott & Kimberly > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Oct 15 18:16:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29477 for ; Fri, 15 Oct 2004 18:16:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIaY7-0007H5-JL for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 18:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIaLb-00028m-9B; Fri, 15 Oct 2004 18:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIaFw-0006ZW-9H for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 18:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28628 for ; Fri, 15 Oct 2004 18:08:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIaRN-00077N-8z for ieprep@ietf.org; Fri, 15 Oct 2004 18:20:50 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Oct 2004 15:09:12 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9FM8Lk4003934; Fri, 15 Oct 2004 15:08:24 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AYC54847; Fri, 15 Oct 2004 15:08:35 -0700 (PDT) Message-Id: <6.1.2.0.2.20041015143120.04c52c58@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 15 Oct 2004 14:39:34 -0700 To: "Steve Silverman" From: Fred Baker Subject: RE: [Ieprep] IDs to consider 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "King, Kimberly S." , "Ieprep \(E-mail\)" 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 11:24 AM 10/15/04 -0400, Steve Silverman wrote: >if the CAC works as advertised, MLEF will have no effect but if for any >reason the CAC is unable to avoid congestion, MLEF will ensure that only >lower priority packets are dropped. Some of us have doubts as to how well >a CAC can work. That's fair. I can demonstrate the result of MLEF when CAC is misconfigured or inoperative, and have in the JUICE demos. Can you demonstrate that CAC is ineffective? >The DOD can not deploy VoIP without a prioritization mechanism. MLEF is >such a prioritization mechanism. See, this is where I go a little nutty. In a circuit switched environment, a circuit is a circuit is a circuit. There is no differentiation between them in any way, and no flag on the data stream exchanged by the circuit that indicates its priority. The only control is in the control plane, and the control is effective for MLPP. In an ATM environment, a VC is a VC is a VC. They have different scheduling algorithms depending on how they were negotiated, but telephony uses something not very different from EF - CBR. There is no differentiation between them in any way, and no flag on the data stream exchanged by the circuit that indicates its priority. The only control is in the control plane, and the control is effective for MLPP. In an IP environment, you state that you not certain that a bandwidth-aware CAC mechanism can possibly work, and state that there is a requirement for a backup plan that imposes DSCP-stamping indicating the priority of the call. The HAIPE folks have stated concerns with this approach on the basis that it identifies the data streams of highest importance to a motivated and capable adversary. But "DOD can not deploy VoIP without a prioritization mechanism". I agree that DoD requires a call prioritization mechanism that is bandwidth-aware and route-aware. I don't understand why it is required in the data plane, or why CAC is suspect given the many years of experience that DoD has with bandwidth-aware/route-aware CAC in other technologies? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Sat Oct 16 10:18:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24052 for ; Sat, 16 Oct 2004 10:18:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIpZx-0007S3-HF for ieprep-web-archive@ietf.org; Sat, 16 Oct 2004 10:30:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIpMr-0004Yj-IN; Sat, 16 Oct 2004 10:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIpMF-00048O-SU for ieprep@megatron.ietf.org; Sat, 16 Oct 2004 10:16:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23813 for ; Sat, 16 Oct 2004 10:16:29 -0400 (EDT) Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIpXq-0007Pm-Bq for ieprep@ietf.org; Sat, 16 Oct 2004 10:28:30 -0400 Received: from Steve (ha30s028.d.shentel.net [204.111.23.28]) by seahorse.shentel.net (8.12.11/8.12.11) with SMTP id i9GEFwwB020003; Sat, 16 Oct 2004 10:15:59 -0400 From: "Steve Silverman" To: "Fred Baker" Subject: RE: [Ieprep] IDs to consider Date: Sat, 16 Oct 2004 10:16:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.1.2.0.2.20041015143120.04c52c58@mira-sjc5-b.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: "King, Kimberly S." , "Ieprep \(E-mail\)" 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit comments below > > > At 11:24 AM 10/15/04 -0400, Steve Silverman wrote: > >if the CAC works as advertised, MLEF will have no effect > but if for any > >reason the CAC is unable to avoid congestion, MLEF will > ensure that only > >lower priority packets are dropped. Some of us have > doubts as to how well > >a CAC can work. > > That's fair. I can demonstrate the result of MLEF when CAC > is misconfigured > or inoperative, and have in the JUICE demos. Can you > demonstrate that CAC > is ineffective? If I demonstrated an ineffective CAC, you would say I did a poor implementation. I think it is up to the vendors to demonstrate an effective CAC under conditions that that customer thinks are realistic. > > >The DOD can not deploy VoIP without a prioritization > mechanism. MLEF is > >such a prioritization mechanism. > > See, this is where I go a little nutty. Take a few deep breaths. :-) > > In a circuit switched environment, a circuit is a circuit > is a circuit. > There is no differentiation between them in any way, and no > flag on the > data stream exchanged by the circuit that indicates its > priority. The only > control is in the control plane, and the control is > effective for MLPP. > > In an ATM environment, a VC is a VC is a VC. They have > different scheduling > algorithms depending on how they were negotiated, but > telephony uses > something not very different from EF - CBR. There is no > differentiation > between them in any way, and no flag on the data stream > exchanged by the > circuit that indicates its priority. The only control is in > the control > plane, and the control is effective for MLPP. > > In an IP environment, you state that you not certain that a > bandwidth-aware > CAC mechanism can possibly work, and state that there is a > requirement for > a backup plan that imposes DSCP-stamping indicating the > priority of the > call. There is a requirement for a backup plan so that critical users call work. How this is to be implemented is to be determined. I haven't figured out a system I trust without packet marking since intermediate routers don't "know" about the connections. The HAIPE folks have stated concerns with this > approach on the basis > that it identifies the data streams of highest importance > to a motivated > and capable adversary. But "DOD can not deploy VoIP without a > prioritization mechanism". This is a legitimate concern that will have to be balanced against the need to ensure critical calls get thru and work. One solution is link encryption of critical links. > > I agree that DoD requires a call prioritization mechanism that is > bandwidth-aware and route-aware. I don't understand why it > is required in > the data plane, or why CAC is suspect given the many years > of experience > that DoD has with bandwidth-aware/route-aware CAC in other > technologies? > Previous experience was with TCP-based applications that were relatively insensitive to occasional packet losses. Voice is different. Have you tested any CAC implementations using silence suppression (Voice Activity Detection) over a limited bandwidth network? Steve _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Oct 18 09:30:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15604 for ; Mon, 18 Oct 2004 09:30:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXmX-0000B6-9o for ieprep-web-archive@ietf.org; Mon, 18 Oct 2004 09:42:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXVd-000078-Uy; Mon, 18 Oct 2004 09:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXQE-0007Px-HX for ieprep@megatron.ietf.org; Mon, 18 Oct 2004 09:19:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14820 for ; Mon, 18 Oct 2004 09:19:33 -0400 (EDT) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXc7-0008O0-CB for ieprep@ietf.org; Mon, 18 Oct 2004 09:31:58 -0400 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id i9IDJFk1016660; Mon, 18 Oct 2004 09:19:23 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0I5S00L017O3B9@lmco.com>; Mon, 18 Oct 2004 09:19:15 -0400 (EDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0I5S0098T7O2IM@lmco.com>; Mon, 18 Oct 2004 09:19:15 -0400 (EDT) Received: from EMSS09M02.us.lmco.com ([158.183.26.5]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 09:19:14 -0400 Date: Mon, 18 Oct 2004 09:19:14 -0400 From: "Eagan, Christopher" Subject: [Ieprep] Question about RSVP based preemption To: ieprep@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [Ieprep] Question about RSVP based preemption Thread-Index: AcS1FRA5xsN7X8QkRYy732cJI6lwrA== content-class: urn:content-classes:message X-OriginalArrivalTime: 18 Oct 2004 13:19:14.0654 (UTC) FILETIME=[105ABFE0:01C4B515] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT Cc: "James M. Polk" , fred@cisco.com 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Regarding the example in Appendix A of draft-baker-tsvwg-mlpp-that-works-02.txt, it seems that RSVP based preemption may unnecessarily drop low priority calls in cases were the preempting call is not completed to the original callee - in cases where the callee's UAS is alive and well but the call for some reason goes unanswered and is forwarded to an alternate party or a global attendant somewhere else on the network. If you have a network snippet like...... Alt Party R Talker | | | | F Caller-----N---------------N------F Callee | | R Talker Where the 2 "R Talkers" are on an existing Routine Call, N are routers where RSVP preemptions may occur, and F Caller / F Callee are participants in a Flash call being set up (and assuming that the current b/w requirements are such that the F's cannot make their call w/o preempting the R's). >From the example in the draft, it looks like the R's will receive the RSVP preemption messages before F Callee's phone rings to prevent dead rings. Is this correct? Is yes, and F Callee doesn't answer the phone for any reason, F Caller will be redirected to F Callee's Alternate Party. In this case the Routine call is unnecessarily preempted. Is my understanding of how this works correct? Is it possible for the RSVP preempting routers to delay the tear down of low priority calls until the high priority stream actually starts? I.e. Mark the low priority stream for preemption, but don't actually tear it down until the b/w is at capacity. Thanks, Chris Christopher Eagan Software Engineer Lockheed Martin, IS&S (301) 240 - 6328 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Oct 18 12:54:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01440 for ; Mon, 18 Oct 2004 12:54:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJayB-0004L8-0H for ieprep-web-archive@ietf.org; Mon, 18 Oct 2004 13:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaSu-0004tP-68; Mon, 18 Oct 2004 12:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJa58-0001T4-T6 for ieprep@megatron.ietf.org; Mon, 18 Oct 2004 12:09:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28075 for ; Mon, 18 Oct 2004 12:09:51 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJaH3-0003R2-MI for ieprep@ietf.org; Mon, 18 Oct 2004 12:22:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2004 09:18:47 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9IG8rk2022283; Mon, 18 Oct 2004 09:08:53 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AYD68970; Mon, 18 Oct 2004 09:09:33 -0700 (PDT) Message-Id: <6.1.2.0.2.20041018073601.04cb5a78@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Oct 2004 09:06:00 -0700 To: "Eagan, Christopher" From: Fred Baker Subject: Re: [Ieprep] Question about RSVP based preemption Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "James M. Polk" , 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db At 09:19 AM 10/18/04 -0400, Eagan, Christopher wrote: >Regarding the example in Appendix A of >draft-baker-tsvwg-mlpp-that-works-02.txt, it seems that RSVP based >preemption may unnecessarily drop low priority calls in cases were the >preempting call is not completed to the original callee That would surprise me except in very narrow cases; as I understand it, those cases also hold in the military PSTN MLPP implementation. in the general case: RFC 3312 (which is reflected in the appendix) describes how RSVP and the application protocol (in this case SIP) interact. The end systems have a fair exchange of application signaling before their IP addresses and port numbers are even known to each other to initiate the RSVP exchange. Part of what has to be determined at the application layer is whether the end system has been turned on (is the plug in the wall?), whether it is currently engaged with another call (which may be preempted in SIP), and so on. In addition, as opposed to the Caspian proposal currently being discussed in TIA, RSVP initiates the reservation in the RESV message originated by the receiver towards the sender, which is a response to the PATH message the sender sent to the receiver. By definition, if there is an RESV message in the system (if someone is trying to install a reservation), a fair SIP exchange has already occurred, the two handsets have decided to engage in a call if possible, and the PATH message has already made it from the sender to the receiver. Now, yes, one does ensure bandwidth before ringing the phone. So if no human actually answers the phone (your specific case), an unnecessary preemption event may have occurred. Now let's take a look at the PSTN case. Any given call proceeds through some number of switches. In the final switch, there is no real question of bandwidth: if the switch can get to the phone, the bandwidth exists, and in any event if the phone having been rung is answered the switch is in a position to handle any issues that might arise. In the N-1 preceding, however, there may or may not be bandwidth to the next switch, and preemption may be used to create that bandwidth. In such a case, the preemption likewise occurs prior to ringing the phone, and therefore before a human has the opportunity to answer or fail to answer. To be frank, while I think it would be good if we could solve both problems simultaneously, I think the premise in this system is that a routine call being dropped here or there is not a big problem. And by the way, James and I are not arguing that routine calls are sacrosanct. We are arguing that *if* a call at any preference level is preempted, one or two should be dropped entirely rather than an entire class of calls being made marginal. >- in cases where the callee's UAS is alive and well but the call for some >reason goes unanswered and is forwarded to an alternate party or a global >attendant somewhere else on the network. > >If you have a network snippet like...... > > Alt Party R Talker > | | > | | >F Caller-----N---------------N------F Callee > | > | > R Talker > >Where the 2 "R Talkers" are on an existing Routine Call, N are routers >where RSVP preemptions may occur, and F Caller / F Callee are participants >in a Flash call being set up (and assuming that the current b/w >requirements are such that the F's cannot make their call w/o preempting >the R's). > > From the example in the draft, it looks like the R's will receive the > RSVP preemption messages before F Callee's phone rings to prevent dead > rings. Is this correct? Is yes, and F Callee doesn't answer the phone > for any reason, F Caller will be redirected to F Callee's Alternate > Party. In this case the Routine call is unnecessarily preempted. > >Is my understanding of how this works correct? > >Is it possible for the RSVP preempting routers to delay the tear down of >low priority calls until the high priority stream actually starts? I.e. >Mark the low priority stream for preemption, but don't actually tear it >down until the b/w is at capacity. > >Thanks, > >Chris > >Christopher Eagan >Software Engineer >Lockheed Martin, IS&S >(301) 240 - 6328 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Oct 19 22:32:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17847 for ; Tue, 19 Oct 2004 22:32:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Tq-0003r9-Uk for ieprep-web-archive@ietf.org; Tue, 19 Oct 2004 22:45:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4ck-0002lT-Hq; Tue, 19 Oct 2004 20:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwzJ-0002bI-5q for ieprep@megatron.ietf.org; Tue, 19 Oct 2004 12:37:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13771 for ; Tue, 19 Oct 2004 12:37:21 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJxBR-0002dB-47 for ieprep@ietf.org; Tue, 19 Oct 2004 12:50:02 -0400 Received: from Mpierce1@aol.com by imo-m24.mx.aol.com (mail_out_v37_r3.8.) id a.195.31b59b7b (25711); Tue, 19 Oct 2004 12:36:42 -0400 (EDT) Message-ID: <195.31b59b7b.2ea69c99@aol.com> Date: Tue, 19 Oct 2004 12:36:41 EDT Subject: Re: [Ieprep] IDs to consider To: KIMBERLY.S.KING@saic.com, ieprep@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit In a message dated 10/15/2004 10:28:34 AM Eastern Daylight Time, KIMBERLY.S.KING@saic.com writes: > draft-baker-tsvwg-mlef-concerns-02.txt > draft-baker-tsvwg-mlpp-that-works-02.txt > > The above IDs are not quite in our charter but they are > relevant to the ieprep mission - we would like people > on the list to review and comment on them with a view > to recommending to the IESG that they > be published as informational RFCs > > The first draft is titled "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements" and was written to argue that MLEF, as described in draft-silverman-tsvwg-mlefphb-00.txt and its predecesors would not meet the DoD's own requirements for MLPP without the use of some form of Capacity Admission Control (CAC). The MLEF draft was reissued as version -01 on October 6, partly to more strongly emphasize that this proposed mechanism must be used with CAC and will fail without it. Therefore, there is no need for continued discussion/consideration of the first draft listed above. Mike Pierce Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Wed Oct 20 10:30:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08799 for ; Wed, 20 Oct 2004 10:30:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHg4-0001oe-Ui for ieprep-web-archive@ietf.org; Wed, 20 Oct 2004 10:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGZd-000441-1q; Wed, 20 Oct 2004 09:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKG0C-0002zf-Jt; Wed, 20 Oct 2004 08:55:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29436; Wed, 20 Oct 2004 08:55:33 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGCV-0008FH-My; Wed, 20 Oct 2004 09:08:25 -0400 Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i9KCsadS011276; Wed, 20 Oct 2004 08:54:46 -0400 (EDT) Subject: Re: [Ieprep] IDs to consider To: Mpierce1@aol.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Wed, 20 Oct 2004 08:55:12 -0400 X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 10/20/2004 08:54:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: KIMBERLY.S.KING@saic.com, ieprep-bounces@ietf.org, 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: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 So maybe we should then also be discussing draft-silverman-tsvwg-mlefphb-01.txt? ---------------------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------------------- Mpierce1 @aol.com To: KIMBERLY.S.KING@saic.com, ieprep@ietf.org Sent by: cc: ieprep-bounces Subject: Re: [Ieprep] IDs to consider 10/19/2004 12:36 PM In a message dated 10/15/2004 10:28:34 AM Eastern Daylight Time, KIMBERLY.S.KING@saic.com writes: > draft-baker-tsvwg-mlef-concerns-02.txt > draft-baker-tsvwg-mlpp-that-works-02.txt > > The above IDs are not quite in our charter but they are > relevant to the ieprep mission - we would like people > on the list to review and comment on them with a view > to recommending to the IESG that they > be published as informational RFCs > > The first draft is titled "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements" and was written to argue that MLEF, as described in draft-silverman-tsvwg-mlefphb-00.txt and its predecesors would not meet the DoD's own requirements for MLPP without the use of some form of Capacity Admission Control (CAC). The MLEF draft was reissued as version -01 on October 6, partly to more strongly emphasize that this proposed mechanism must be used with CAC and will fail without it. Therefore, there is no need for continued discussion/consideration of the first draft listed above. Mike Pierce Artel _______________________________________________ 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