From mailman-bounces@ietf.org Sun Aug 1 06:51: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 GAA11219 for ; Sun, 1 Aug 2004 06:51:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrDyj-0001Fv-BB for tsvwg-archive@ietf.org; Sun, 01 Aug 2004 06:54:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCV6-0007qI-IC for tsvwg-archive@ietf.org; Sun, 01 Aug 2004 05:19:28 -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: tsvwg-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:04:44 -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 tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From tsvwg-bounces@ietf.org Sun Aug 1 20:12:49 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 UAA04344; Sun, 1 Aug 2004 20:12:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrQUQ-0003TP-Ur; Sun, 01 Aug 2004 20:15:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrQNB-00068b-Pz; Sun, 01 Aug 2004 20:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrQ9Z-0000WF-Pc for tsvwg@megatron.ietf.org; Sun, 01 Aug 2004 19:54:09 -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 TAA03042 for ; Sun, 1 Aug 2004 19:54:06 -0400 (EDT) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrQCJ-00038F-61 for tsvwg@ietf.org; Sun, 01 Aug 2004 19:57:00 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id i71NrVZB004434 for ; Sun, 1 Aug 2004 23:53:31 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Sun, 1 Aug 2004 19:53:31 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D12980F7E24@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Sun, 1 Aug 2004 19:53:30 -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.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Tsvwg] draft agenda for 8/5 9:00AM tsvwg meeting X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Below find a draft agenda for the TSVWG meeting this week. Please let us know if you have any suggested add/change/deletes. ---- Transport Area WG (tsvwg) Thursday, August 5 at 0900-1130 =============================== CHAIRS: Allison Mankin Jon Peterson 0900 Agenda bashing/Notetaker/Intro (chairs) 0910 TCP MIB Extensions Update (Mathis) http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-05.tx t 0920 RSVP Aggregation (Davie) http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt 0935 RSVP Aggregation (Polk) http://www.ietf.org/internet-drafts/draft-polk-rsvp-aggregate-reduction-00.t xt 0950 Diffserv Basic Classes Reviews (Black/Corson, Chan) http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-03.tx t 1015 Real-time ECN Update (Babiarz) http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-01.txt 1020 LTCP Placement Discussion (here or TCPM?) (Bhandarkar) http://www.ietf.org/internet-drafts/draft-bhandarkar-ltcp-01.txt 1030 SCTP Bakeoff report & Miscellaneous SCTP Status (Stewart) 1045 Localized RSVP (Manner) http://www.ietf.cnri.reston.va.us/internet-drafts/draft-manner-lrsvp-03.txt 1055 Dynamic Addressing of Transport-Layer Connections - Open Discussion (Mankin) ???? Other business? Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Aug 3 03:56:09 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 DAA22795; Tue, 3 Aug 2004 03:56:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BruCb-0005Vt-L0; Tue, 03 Aug 2004 03:59:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bru7h-0005gr-8N; Tue, 03 Aug 2004 03:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bru13-0003Xw-I9 for tsvwg@megatron.ietf.org; Tue, 03 Aug 2004 03:47:21 -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 DAA22464 for ; Tue, 3 Aug 2004 03:47:19 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bru41-0005PN-Ux for tsvwg@ietf.org; Tue, 03 Aug 2004 03:50:29 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i737lFCo021018 for ; Tue, 3 Aug 2004 09:47:15 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i737lExA015632 for ; Tue, 3 Aug 2004 09:47:14 +0200 Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i737lEU9011182 for ; Tue, 3 Aug 2004 09:47:14 +0200 Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Aug 2004 09:47:13 +0200 Message-ID: From: Schruefer Wolfgang To: tsvwg@ietf.org Date: Tue, 3 Aug 2004 09:47:12 +0200 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: de4f315c9369b71d7dd5909b42224370 Subject: [Tsvwg] SCTP: which ABORT cause code after exceeded retransmissions? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hello, at the SCTP Interop in Muenster I noticed at least 2 implementations which sent an additional ABORT when a association was deleted due to no reponse from the peer (exceeded retransmissions). Although this behaviour is not standardized I think it has some advantage (e.g. for fault detection) compared to a silent deletion and I would like to implement it also. But to identify this type of ABORT I am not sure which ABORT cause code I may use. My favourite solution would be to suggest a new cause code in the implementers guide, otherwise probably I would use "User Initiated Abort" as an workaround. What do others think? Viele Gruesse Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Aug 4 17:31:46 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 RAA09830; Wed, 4 Aug 2004 17:31:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTPp-0000cs-Fx; Wed, 04 Aug 2004 17:35:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTFJ-0001zA-26; Wed, 04 Aug 2004 17:24:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTDK-0001Lc-Jw for tsvwg@megatron.ietf.org; Wed, 04 Aug 2004 17:22: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 RAA09300 for ; Wed, 4 Aug 2004 17:22:20 -0400 (EDT) Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTGg-0000Tm-21 for tsvwg@ietf.org; Wed, 04 Aug 2004 17:25:51 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i74LMIEf028686 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 Aug 2004 17:22:18 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.10/8.12.5) with ESMTP id i74LMGOp016471; Wed, 4 Aug 2004 17:22:17 -0400 (EDT) Date: Wed, 4 Aug 2004 17:18:26 -0400 (EDT) From: Matt Mathis To: Kristine Adamson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailer2.psc.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tsvwg@ietf.org Subject: [Tsvwg] TCP-ESTATS-MIB: discussion and where are the per connection counters? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I am expecting to make a very short presentation on the MIB at tsvwg tomorrow, but it will not be a good venue to get into detailed discussion of individual objects. It would be extremely helpful if we can arrange a hallway conversation about it - there are a number of MIB/SMI issues that are beyond my expertise. TCP-ESTATS-MIB does not include the counters below, but does have equivalent counters with slightly different names and definitions under tcpEStatsDataTable. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- "My heart is in the work." -- Andrew Carnegie On Wed, 28 Jul 2004, Kristine Adamson wrote: > Hello, > During the upgrading of the TCP-MIB by the IPv6 working group, so that > it would support both IPv4 and IPv6 TCP connections, the following per > connection counter MIB objects were, at one time, defined as part of the > tcpConnectionTable: > tcpConnectionInSegs, tcpConnectionOutSegs, tcpConnectionInOctets, > tcpConnectionOutOctets, tcpConnectionHCInSegs, tcpConnectionHCOutSegs, > tcpConnectionHCInOctets, tcpConnectionHCOutOctets, and tcpConnectionAge > > They were removed from one of the TCP-MIB drafts. At the time I thought > the IPv6 MIB team expected these MIB objects to be added to the > TCP-ESTATS-MIB, but I don't see them in the tcpEStatsConnectionTable in > the current draft of the TCP-ESTATS-MIB. Are these per connection > counters going to be added to the tcpEStatsConnectionTable? Thanks, > > Kristine Adamson > IBM z/OS Communications Server: TCP/IP Development > Phone: (919) 254-7911 T/L 444-7911 > Internet e-mail:adamson@us.ibm.com > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 5 12:27:31 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 MAA28055; Thu, 5 Aug 2004 12:27:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsl96-0000bD-Gq; Thu, 05 Aug 2004 12:31:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BskyV-0003fE-4u; Thu, 05 Aug 2004 12:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsksP-0001X9-EG for tsvwg@megatron.ietf.org; Thu, 05 Aug 2004 12:13:57 -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 MAA27138 for ; Thu, 5 Aug 2004 12:13:54 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bskvu-0000KO-Jk for tsvwg@ietf.org; Thu, 05 Aug 2004 12:17:36 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i75GDLx18691; Thu, 5 Aug 2004 12:13:21 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPXPAML8; Thu, 5 Aug 2004 12:13:20 -0400 Received: from KCHAN-2K3.nortelnetworks.com (asc3t0a3.us.nortel.com [47.81.8.79]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSKYPZBX; Thu, 5 Aug 2004 12:13:18 -0400 Message-Id: <6.0.3.0.0.20040805120451.03b5cc60@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 05 Aug 2004 12:12:16 -0400 To: tsvwg@ietf.org From: Kwok Ho Chan Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_703751==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: Jozef Z Babiarz , Kwok Ho Chan , Fred Baker , jon.peterson@neustar.biz, mankin@psg.com Subject: [Tsvwg] Slides for DiffServ Basic Classes draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 --=====================_703751==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is the slides for the DiffServ Basic Classes draft presentation at the TSVWG WG at 60th IETF @ San Diego. Please use this for the Proceedings. Thank you! -- Kwok Ho Chan -- --=====================_703751==_ Content-Type: application/octet-stream; name="DiffServ_BasicClasses_60thIETF.ppt"; x-mac-type="534C4433"; x-mac-creator="50505433" Content-Disposition: attachment; filename="DiffServ_BasicClasses_60thIETF.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAFwAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////IwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v////7///8iAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAD+/////v////7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAFBo2+T/esQB GAAAAEADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAligAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAACMEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQCAAAAAAAADwDo A7QOAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAA4AAAAAAAAAAQAAAAABAAEPAPID YAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB5gAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAKLgSABC4EgCh0AcwCAAAAAAAAAAouBIAOkEJMCC4EgAAAAYSEAC3D0QA AABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAACi4EgAQuBIAodAHMAgAAAAAAAAAKLgS ADpBCTAguBIAAAAEAAAApA8IAAAAgABAAAAA//8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAA BwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAA AP//7wAAAAAAAQD/////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAA AAAABQAAgASABAAAAAAPAAsE+AAAAA8AAPDwAAAAAAAG8JgAAAAIRAAAEgAAABwAAAAHAAAAAQAA AAcAAAAAAAAACAAAAAAAAAAGAAAAAgAAAAQAAAADAAAABAAAAAQAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAoAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAsAAAAE AAAAAAAAAAQAAAAMAAAACAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAI xUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAA AAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBzMBAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAA HwAUBBwAAAAAABUEFAAAANI3KAQAypo7rQeUxwDKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA /QM0AAAATAAAAGQAAABMAAAAZAAAAAgAAAAAAAAAQLgSADpBCTAAAAAAAAAAAKL9//+a////AQAS AHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAA ZAAAAGQAAABsuBIA6iQJMKi5EgDcL9AAAAAAAAAAAAAAAAAAAAAAAAABEgAPAIgTOAAAAA8AihMw AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZD4IA AAAAANoPBAAAAAAALQAAALoPHAAAAEEAdQBnAHUAcwB0ACAANQAsACAAMgAwADAANAAgALoPSgAA AGQAcgBhAGYAdAAtAGIAYQBrAGUAcgAtAGQAaQBmAGYAcwBlAHIAdgAtAGIAYQBzAGkAYwAtAGMA bABhAHMAcwBlAHMALQAwADMATwDZDwwAAAAAANoPBAAAAA0APQAPAPAPDwoAAAAA8wMUAAAAAwAA AAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPbQAAAERpZmZTZXJ2IFNlcnZpY2UgQ2xh c3NlcyAtMDMLKGRyYWZ0LWJha2VyLWRpZmZzZXJ2LWJhc2ljLWNsYXNzZXMtMDMudHh0KQsgZm9y IFRTVldHCyBhdAs2MHRoIElFVEYgQCBTYW4gRGllZ28AAKEPPgAAAG4AAAAAAAAAAAAdAAAAAAAC ACgAKwAAAAAAAgAcABIAAAAAAAIAKAACAAAAAAAKACgAHgASAAAAAAACACgAAACqDxIAAAAIAAAA AQAAAAMAZgAAAAAAAAAQAJ8PBAAAAAUAAAAAAKgPNAAAAEF1Z3VzdCA1LCAyMDA0DUpvemVmIEJh YmlhcnoNS3dvayBIbyBDaGFuDUZyZWQgQmFrZXIAAKEPFgAAADUAAAAAAAAQAABQADUAAAAAAAIA HAAAAKoPLAAAAA8AAAAAAAAABQAAAAEAAAADAAEAAAAAAAAABwAAAAEAAAADABkAAAAAAAAAAADz AxQAAAAEAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8HAAAAT3V0bGluZRAAnw8E AAAAAQAAAAAAqA9SAAAASXNzdWVzIGluIHZlcnNpb24gLTAzIGZyb20gb3RoZXIgcmV2aWV3ZXJz DU1ham9yIGNoYW5nZXMgZnJvbSB2ZXJzaW9uIDAyDU5leHQgU3RlcAAA8wMUAAAABQAAAAAAAAAC AAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGwAAAElzc3VlcyBmcm9tIG90aGVyIHJldmlld2Vy cxAAnw8EAAAAAQAAAAAAoA84AwAAQQBkAGQAIABzAHQAYQB0AGUAbQBlAG4AdAAgAHQAbwAgAHMA ZQBjAHQAaQBvAG4AIAAxACAAdABvACAAYwBsAGEAcgBpAGYAeQAgAHQAaABhAHQAIABmAG8AdQBy ACAAQQBGACAAYQBuAGQAIABvAG4AZQAgAEUARgAgAHMAdABhAG4AZABhAHIAZABpAHoAZQBkACAA YwBvAGQAZQAgAHAAbwBpAG4AdAAgAHcAYQBzACAAYQByAGIAaQB0AHIAYQByAHkALgAgAFQAaABl ACAARABpAGYAZgBTAGUAcgB2ACAAQQByAGMAaABpAHQAZQBjAHQAdQByAGUAIABhAGwAbABvAHcA cwAgAGEAbgB5ACAAcgBlAGEAcwBvAG4AYQBiAGwAZQAgAG4AdQBtAGIAZQByACAAbwBmACAAQQBG ACAAYQBuAGQAIABFAEYAIABQAEgAQgBzACAAJiANAFIAZQBzAG8AbAB1AHQAaQBvAG4AOgAgAEEA ZwByAGUAZQBkAA0AQQBsAG0AbwBzAHQAIABhAGwAbAAgAHQAaABlACAATQBVAFMAVABzACAAaQBu ACAAdABoAGUAIABkAG8AYwB1AG0AZQBuAHQAIABzAGgAbwB1AGwAZAAgAGIAZQAgAFMASABPAFUA TABEAHMALgAgACAARQB4AGMAZQBwAHQAIABmAG8AcgAgAHQAaABlACAATQBVAFMAVAAgAHQAaABh AHQAIAByAGUAZgBlAHIAIAB0AG8AIAB0AGgAZQAgAG0AdQBzAHQAcwAgAGkAbgAgAEQAaQBmAGYA UwBlAHIAdgAgAFAASABCACAAUgBGAEMAcwAuAA0AUgBlAHMAbwBsAHUAdABpAG8AbgA6ACAAQQBn AHIAZQBlAGQALAAgAHcAaQBsAGwAIAByAGUAdgBpAGUAdwAgAHQAaABlACAAdQBzAGEAZwBlACAA bwBmACAATQBVAFMAVAAvAFMASABPAFUATABEACAAaQBuACAAdABoAGUAIABkAG8AYwB1AG0AZQBu AHQAIABhAG4AZAAgAHIAZQB2AGkAcwBlACAAYQBjAGMAbwByAGQAaQBuAGcALgAAAKEPXAAAALAA AAAAAAAQAABaABMAAAABAAAQAABaAHsAAAAAAAAQAABaAF8AAAABAAAQAABaALAAAAAAAAIAHAAT AAAAAAACABgAewAAAAAEAgAABBwAXwAAAAAIAgAACBgAAACqD3QAAABpAAAAAAAAAAgAAAABAAAA AwA4AAAAAAAAAAQAAAABAAAAAwAlAAAAAAAAAAUAAAABAAAAAwAbAAAAAAAAAAcAAAABAAAAAwAy AAAAAAAAAAgAAAABAAAAAwAFAAAAAAAAAAQAAAABAAAAAwBhAAAAAAAAAAAA8wMUAAAADAAAAAAA AAACAAAACQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHQAAAE1ham9yIENoYW5nZXMgZnJvbSB2ZXJz aW9uIDAyEACfDwQAAAABAAAAAACoDyABAABTZWN0aW9uIDEgcmVzdHJ1Y3R1cmVkIGZvciBiZXR0 ZXIgZmxvdy4NU2VjdGlvbiAyLCAzLCA0IHJld29yZGVkIHRvIHJlZmxlY3Qgc2luZ2xlIFBIQiAo b3IgUEhCIGdyb3VwKSBwZXIgc2VydmljZSBjbGFzcy4NQWRkZWQgU2lnbmFsaW5nLCBSZWFsLXRp bWUgSW50ZXJhY3RpdmUsIEJyb2FkY2FzdCBWaWRlbywgYW5kIE9BTSBzZXJ2aWNlIGNsYXNzZXMu DUFkZGVkIEZpZ3VyZSAxIHRvIGluZGljYXRlIHRoZSB0cmFmZmljIGJlaGF2aW9yIGNoYXJhY3Rl cmlzdGljIG9mIGVhY2ggc2VydmljZSBjbGFzcy4AAKEPNgAAAHkAAAAAAAAAAABSAAAAAQAAAAAA VgAAAAAAAAAAAHkAAAAAAAAAUgAAAAAAAABWAAAAAAAAAAAA8wMUAAAACwAAAAAAAAACAAAACAEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAE5leHQgU3RlcHMQAJ8PBAAAAAEAAAAAAKgPGQEAAEJh c2VkIG9uIHJlc3VsdCBvZiBSZXZpZXdlciBhbmQgQ28tQXV0aG9yIG9mZmxpbmUgbWVldGluZ3Mg aGVyZSBpbiBTYW4gRGllZ28NZ2VuZXJhdGUgYW4gb3BlbiBpc3N1ZXMgbGlzdCwNZ2VuZXJhdGUg YSBuZXcgdmVyc2lvbiBvZiBkcmFmdCB0aGF0IHJlc29sdmVzIHRoZXNlIGlzc3VlcywNbWFpbnRh aW4gdGhlIG9wZW4gaXNzdWVzIGxpc3QuDVJlcXVlc3QgZm9yIGluZGljYXRpb24gb2YgbWF0dXJp dHkgb2YgZHJhZnQgYW5kIHNldHVwIHNvbWUgc2NoZWR1bGUgZm9yIGNvbXBsZXRpb24uAAChDzYA AABNAAAAAAAAAAAAeQAAAAEAAAAAAFQAAAAAAAAAAABNAAAAAAAAAHkAAAAAAAAAVAAAAAAAAAAA AOoDAAAAAA8A+AOcCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAAEgBgAPAHIAAAAP// /wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAAAAP8A////AAAAAAD//wAA/5kA AAD//wD/AAAAlpaWAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPMAP/MZgBgAPAH IAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD///8AAAAAAICAgAAA AAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A/wAAAACZ AABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4AAAABAP/9PwAA ACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAABAP////8sAAAAAAMAABAA ow98AAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAABwAAAP//7wAAAAAAAQD/ ////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIA FACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIA AAAABwAAAP//7wAAAAAAAQD/////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAg AQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMP DAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAA AAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAA AAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBNYEAAAPAALwzgQA ABAACPAIAAAABgAAAAYEAAAPAAPwZgQAAA8ABPAoAAAAAQAJ8BAAAAD19fX19fX19fX19fX19fX1 AgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwABAAEAgAAw eNAAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACAAbAB 0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQDQAA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABD bGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAA AQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEAAQCAAMh60ACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMML CAAAAAEAAAACANAADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlm dGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAA AAEAAAAAAA8ABPC2AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAEAgAB0gdAAgQEEAAAI gwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaAEA8AEfAQAAAAAADD CwgAAAACAAAABwHQAA8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAA AAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABQQAAAAKAACDAAvwMAAA AH8AAQABAIAAOIbQAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA YA+wB9AOgBAPABHwEAAAAAAAwwsIAAAAAwAAAAkC0AAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8C AAAAKgAAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIA CvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQABAIAAAIvQAIEBBAAACIMBAAAACL8BAQARAMABAQAA CP8BAQAJAAECAgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgC0AAPAA3w QAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAA ANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB jp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgAgALoPHAAAAEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAPAD +gUAAAEA8QMIAAAAAAAAgAAACjAPAAwEegUAAA8AAvByBQAAwAAI8AgAAAAHAAAAB0QAAA8AA/AK BQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABEAAAFAAAADwAE8MgA AAASAArwCAAAAAJEAAAACgAAgwAL8DAAAAB/AAEABQCAAMA76AGBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAugB DwAN8FAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAA8ABPDKAAAAEgAK8AgAAAADRAAAAAoAAIMA C/AwAAAAfwABAAUAgACc9OgBgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAAAAAI8J3xAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwDoAQ8ADfBSAAAAAACfDwQAAAAEAAAA AACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA+A8EAAAAAAAAAAAAqg8K AAAAAgAAAAEAAAAAAA8ABPBkAAAAEgAK8AgAAAAERAAAAAoAAGMAC/AkAAAAfwAEAQQBhwABAAAA fwEAAAEAvwERABEA/wEIAAkAPwIBAAEAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgAAAAC AAAABQDoAQ8ABPAWAQAAEgAK8AgAAAAFRAAAAAoAAIMAC/AwAAAAfwABAAUAgADc+ugBgQEEAAAI gwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACwCrABMA/QFA8AEfAQAAAAAADD CwgAAAADAAAABgLoAQ8ADfCeAAAAAACfDwQAAAACAAAAAACoD1IAAABDbGljayB0byBlZGl0IE1h c3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZp ZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAAAFMA AAABAAAAAAAPAATwzgAAABIACvAIAAAABkQAAAAKAACTAAvwNgAAAH8AAQAFAIAAZARjBYcAAgAA AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXxUAAFAHfxYPABHw EAAAAAAAwwsIAAAABAAAAAkCYwUPAA3wUAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAA AAIAAAAAAAAAAAACAAAAAAACAAwAAAD6DwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAADwAE8NAA AAASAArwCAAAAAdEAAAACgAAkwAL8DYAAAB/AAEABQCAAGALYwWHAAIAAACBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF8VjwnfEH8WDwAR8BAAAAAAAMMLCAAAAAUA AAAIAmMFDwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgAC AAAAAAACAAwAAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAADwAE8EgAAAASAArwCAAAAAFE AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoT MAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAD/esQBIEn2bg8A7gMk AgAAAgDvAxgAAAAAAAAADxAAAAAAAAAAAACAAAAAAAcAEgAPAAwElAEAAA8AAvCMAQAAIAAI8AgA AAADAAAAAxAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAQAAAFAAAADwAE8HIAAAASAArwCAAAAAIQAAAgAgAAUwAL8B4AAAB/AAAABACAAHAv0AC/AQAA AQD/AQAAAQABAwIEAAAAABDwCAAAAFAEsAHQFO4HDwAR8BAAAAAAAMMLCAAAAAAAAAAPANAADwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxAAACACAABTAAvwHgAAAH8AAAAEAIAA +PHQAL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAgApgAyAT0A4PABHwEAAAAAAAwwsIAAAAAQAA ABAA0AAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAvHjEAeCwsJAPAO4DJAIAAAIA7wMYAAAAAQAA AA0OAAAAAAAAAAAAgAAAAAAHABIADwAMBJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMUAAAPAAPw JAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPBy AAAAEgAK8AgAAAACFAAAIAIAAFMAC/AeAAAAfwAAAAQAgACQN+gBvwEAAAEA/wEAAAEAAQMCBAAA AAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQDoAQ8ADfAMAAAAAACeDwQAAAAA AAAADwAE8HIAAAASAArwCAAAAAMUAAAgAgAAUwAL8B4AAAB/AAAABACAAJhB6AG/AQAAAQD/AQAA AQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAOgBDwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAARQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB jp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAOsuCAAAALx4xAEg7aiUDwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAA AAAABwASAA8ADASUAQAADwAC8IwBAABAAAjwCAAAAAMAAAADGAAADwAD8CQBAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgAAAUAAAAPAATwcgAAABIACvAIAAAAAhgA ACACAABTAAvwHgAAAH8AAAAEAIAAvPnQAL8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAkACwAdAU MAMPABHwEAAAAAAAwwsIAAAAAAAAAA0A0AAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK 8AgAAAADGAAAIAIAAFMAC/AeAAAAfwAAAAQAgABEnNAAvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgA AABgA7AB0BQADw8AEfAQAAAAAADDCwgAAAABAAAADgDQAA8ADfAMAAAAAACeDwQAAAABAAAADwAE 8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCy srIADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggA AADUeMQBIJymjg8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEgAPAAwElAEA AA8AAvCMAQAAsAAI8AgAAAADAAAAAzwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAA8AAAFAAAADwAE8HIAAAASAArwCAAAAAI8AAAgAgAAUwAL8B4AAAB/ AAAABACAAKRd6AG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAGAAsAHQFDADDwAR8BAAAAAAAMML CAAAAAAAAAANAOgBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAzwAACACAABT AAvwHgAAAH8AAAAEAIAAeF7oAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA0AKwAdAUAA8PABHw EAAAAAAAwwsIAAAAAQAAAA4A6AEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAAB PAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBM4AAAADwCK EzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAo3nEAfBovT0PAO4D JAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABIADwAMBJQBAAAPAALwjAEAAKAACPAI AAAAAwAAAAMwAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAAMAAABQAAAA8ABPByAAAAEgAK8AgAAAACMAAAIAIAAFMAC/AeAAAAfwAAAAQAgABQ5dAAvwEA AAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACQALAB0BRgAw8AEfAQAAAAAADDCwgAAAAAAAAADQDQAA8A DfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMwAAAgAgAAUwAL8B4AAAB/AAAABACA AADo0AC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJADsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEA AAAOANAADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAATAAAAAMAACDAAvwMAAA AIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA ////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAIB5xAHwKqDeAAByFywAAAABAFAAAAAAALwO AABiHQAAjh8AALohAAALACAAEiYAAOYjAAAOABAAYBcAAAAA9Q8cAAAACAEAAG0QAAMAAAAAPigA AAEAAAAOAAAAAQAQBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAP7///8MAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////+/wAABQACAAAAAAAAAAAAAAAAAAAAAAAB AAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAB0AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQA AAC0AAAABgAAALwAAAAHAAAAxAAAAAgAAADMAAAACQAAANQAAAAKAAAA3AAAABcAAADkAAAACwAA AOwAAAAQAAAA9AAAABMAAAD8AAAAFgAAAAQBAAANAAAADAEAAAwAAAAUAgAAAgAAAOQEAAAeAAAA DwAAAE9uLXNjcmVlbiBTaG93AGUeAAAAAQAAAABuLXMDAAAAligAAAMAAAAZAAAAAwAAAAUAAAAD AAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAexAKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAAHhAAAAgAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAYAAABBcmlhbAAPAAAARGVmYXVsdCBE ZXNpZ24AbgAAAERpZmZTZXJ2IFNlcnZpY2UgQ2xhc3NlcyAtMDMgKGRyYWZ0LWJha2VyLWRpZmZz ZXJ2LWJhc2ljLWNsYXNzZXMtMDMudHh0KSAgZm9yIFRTVldHICBhdCA2MHRoIElFVEYgQCBTYW4g RGllZ28ACAAAAE91dGxpbmUAHAAAAElzc3VlcyBmcv7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAFwQAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQAAACQAAAABwAA AJwAAAAIAAAAqAAAAAkAAADAAAAAEgAAAMwAAAAKAAAA7AAAAAwAAAD4AAAADQAAAAQBAAAPAAAA EAEAABEAAAAYAQAAAgAAAOQEAAAeAAAAGAAAAFBvd2VyUG9pbnQgUHJlc2VudGF0aW9uAB4AAAAB AAAAAG93ZR4AAAABAAAAAG93ZR4AAAANAAAAS3dvayBIbyBDaGFuAGVzZR4AAAADAAAAMTUAax4A AAAVAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQAb24AQAAAALDRtoMgAAAAQAAAAAAAAAAAAAAAQAAA APC50OT/esQBAwAAAM8AAABHAAAAPA8AAP////8DAAAACACJEGcMAAABAAkAAAOWBwAABQAfAAAA AAAEAAAAAwEIAAUAAAALAgAAAAAFAAAADALvAukDAwAAAB4ABwAAAPwCAAD///8AAAAEAAAALQEA AAgAAAD6AgUAAAAAAP///wAEAAAALQEBAAwAAABACSEA8AAAAAAAAADvAukD/////wgAAAD6AgAA AAAAAAAAAAAEAAAALQECAAQAAAAtAQAABAAAACcB//8cAAAA+wLI/wAAAAAAAJABAAAAAABAABJU aW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUA AAAJAgAAAAITAAAAMgqpALEACAAAAERpZmZTZXJ2KAAPABMAEwAeABkAEwAbAAQAAAAuAQAAHAAA APsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAAAAAAAAGAAAAECzEgABAAAA5AQAAAAAAAAEAAAA LQEEAAQAAADwAQMAHAAAAPsCyP8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAA AAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACHwAAADIKqQCBARAA AABTZXJ2aWNlIENsYXNzZXMgHgAZABMAHAAPABkAGQAOACUADwAZABYAFgAZABYADgAEAAAALgEA AAQAAAAtAQQABAAAAPABAwAcAAAA+wLI/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4A AAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgqp AOwCAQAAAC0tEgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLI/wAAAAAAAJABAAAAAABA ABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEB AAUAAAAJAgAAAAIKAAAAMgqpAP4CAgAAADAzHAAcAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwA AAD7Atn/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAAAAAAAAAAAAAAAAAAABAAA AC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhAAAAAyCtwArwAGAAAAKGRyYWZ0DQAUAA0A EQAMAAsABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2f8AAAAAAACQAQAAAAAAQAASVGlt ZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACCQAAADIK3AAFAQEAAAAtLQ0ABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2f8A AAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACDwAAADIK3AASAQUAAABiYWtlcnQTABIAEwARAA4ABAAA AC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2f8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJv bWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAA ADIK3ABpAQEAAAAtLQwABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2f8AAAAAAACQAQAA AAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAA AAIBAQAFAAAACQIAAAACEwAAADIK3AB1AQgAAABkaWZmc2VydhQACwANAAwADwARAA4AEwAEAAAA LgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9t YW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAA MgrcAO4BAQAAAC0tDQAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAA AABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAIPAAAAMgrcAPsBBQAAAGJhc2ljZRMAEgAPAAsAEgAEAAAALgEAAAQAAAAt AQQABAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAA AAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgrcAEwCAQAA AC0tDAAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1l cyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJ AgAAAAISAAAAMgrcAFgCBwAAAGNsYXNzZXN2EQALABEADwAPABEAEAAEAAAALgEAAAQAAAAtAQQA BAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgrcAMQCAQAAAC0t DAAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1lcyBO ZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAISAAAAMgrcANACBwAAADAzLnR4dCl2FAAUAAoACwATAAsADQAEAAAALgEAAAQAAAAtAQQABAAA APABAwAcAAAA+wLI/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIVAAAAMgoaAXEBCQAAAGZvciBU U1ZXRwITABwAEwANACMAHgAoADQAKAAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLI/wAA AAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAA AC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIKAAAAMgpdAeYBAgAAAGF0GQAQAAQAAAAuAQAABAAAAC0B BAAEAAAA8AEDABwAAAD7Asj/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAAAAAAA AAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgoAAAAyCqAB7AACAAAA NjAcABwABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2v8AAAAAAACQAQAAAAAAQAASVGlt ZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACCgAAADIKjwEkAQIAAAB0aAsAEwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLI /wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMA BAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIfAAAAMgqgAU8BEAAAAElFVEYgQCBTYW4gRGllZ28T ACEAIwAeAA4ANAAOAB4AGQAcAA4AKAAPABkAGwAcAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwA AAD7Atn/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAAAAAAAAAAAAAAAAAAABAAA AC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhwAAAAyCvYBfAEOAAAAQXVndXN0IDUsIDIw MDQcABQAEwAUAA8ACwAJABQACgAJABQAEwAUABQABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAA APsC2f8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDwAAADIKJQKKAQUAAABKb3plZnQPABMAEQAS AAwABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC2f8AAAAAAACQAQAAAAAAQAASVGltZXMg TmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIA AAACEgAAADIKJQLlAQcAAABCYWJpYXJ6dhoAEQATAAsAEQANABEABAAAAC4BAAAEAAAALQEEAAQA AADwAQMAHAAAAPsC2f8AAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAA AAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACGQAAADIKUwJ6AQwAAABLd29r IEhvIENoYW4bAB0AEwATAAsAGwATAAoAGgAUABEAFAAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAc AAAA+wLZ/wAAAAAAAJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIWAAAAMgqCAp0BCgAAAEZyZWQgQmFrZXIW AA0AEQAUAAoAGgARABMAEQANAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAG9tIG90aGVyIHJldmlld2VycwAeAAAATWFqb3IgQ2hhbmdl cyBmcm9tIHZlcnNpb24gMDIACwAAAE5leHQgU3RlcHMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVz ZWQAAwAAAAIAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUg VGl0bGVzAAMAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8kAAAAFAAAAF/A keNyKAAADAD0AwMAYwVLd29rIEhvIENoYW4IAAAASwB3AG8AawAgAEgAbwAgAEMAaABhAG4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --=====================_703751==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_703751==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --=====================_703751==_-- From tsvwg-bounces@ietf.org Thu Aug 5 13:15: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 NAA00885; Thu, 5 Aug 2004 13:15:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsltU-0001Ku-No; Thu, 05 Aug 2004 13:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BslkN-0005Uv-ET; Thu, 05 Aug 2004 13:09:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsldu-00048L-JK for tsvwg@megatron.ietf.org; Thu, 05 Aug 2004 13:03:02 -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 NAA00063 for ; Thu, 5 Aug 2004 13:02:59 -0400 (EDT) Message-Id: <200408051702.NAA00063@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BslhQ-0001BV-Jd for tsvwg@ietf.org; Thu, 05 Aug 2004 13:06:41 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bslds-000OBu-94 for tsvwg@ietf.org; Thu, 05 Aug 2004 17:03:00 +0000 To: tsvwg@ietf.org Date: Thu, 05 Aug 2004 10:03:00 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Tsvwg] A Review on Diffserv Basic Classes draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Here's the third of the reviews for the Review-Session on draft-baker-diffserv-basic-classes-03.txt. This is the one whose reviewer definitely can't be here today for the in-person discussants. (The other reviewer/discussants are David Black, black_david@emc.com, and Brian Carpenter, brc@zurich.ibm.com) Alan O'Neill Flarion A.ONeill@flarion.com ------------------------------------------------------------- Wg, As one of the volunteers from Seoul to review this draft, here are some high-level comments (included below) on the draft. So firstly the deafening silence to the specific call for volunteer could be interpreted (amongst others) as the work being targeted at the wrong wg, wg attendees wanting to avoid a detailed review of a big detailed draft that was outside of their immediate interest / expertise, or potentially complete disinterest in the wg through to complete disinterest in any IETF wg for this work. I personally believe the work is eminently useful for both vendors and operators, and also useful for operators and customers, as it helps facilitate an abstraction/ generalisation for discussing and agreeing requirements and solutions. I have no view on the appropriate wg for this, but absolutely believe that the work is both important and timely, and the presented draft a very big step towards a very useful BCP. The draft is not, I believe, intended to break the clean separation in diff-serv between PHBs and DSCPs and between DSCPs and applications. I was one of the strong proponents for that separation in the diff-serv wg to ensure that operator degrees of freedom are not standardised away at some arbitrary point in time, as a result of a narrow view of what might be required in the future. That separation was however also not intended to facilitate a DSCP free-for-all per domain, nor a resulting multi-lateral inter-domain DSCP intent / remarking fog. The intention was simply to let the market decide via interations between vendors/operators and customers as to what app/class/DSCP/PHB combinations make sense in specific domains, and what generalisations can then be discovered at specific phases of the development of the DSCP Internet. All I feel this BCP will do is enable those service classes that exist today are evolving in real networks to be captured, documented and the knowledge distributed to enable the accumulated experience to propagate, and hence to further accelerate comprehension, adoption and common configuration. The draft just needs to ensure it does not go beyond 'recommendations' so that we maintain the abstractions, and do not lose the flexibility for the future evolution of the constrained set of DSCP values. I have no problems with the technical contents of the draft and believe it clearly already represents significant community consensus. Regards, Alan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 5 14:35: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 OAA05320; Thu, 5 Aug 2004 14:35:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsn97-0002Yk-81; Thu, 05 Aug 2004 14:39:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsmxO-0002dR-JS; Thu, 05 Aug 2004 14:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsmtE-0001ud-M0 for tsvwg@megatron.ietf.org; Thu, 05 Aug 2004 14:22:56 -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 OAA04323 for ; Thu, 5 Aug 2004 14:22:54 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsmwi-0002Je-PF for tsvwg@ietf.org; Thu, 05 Aug 2004 14:26:36 -0400 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 05 Aug 2004 21:22:50 +0300 Date: Thu, 5 Aug 2004 21:22:49 +0300 (EEST) From: Jukka MJ Manner To: tsvwg@ietf.org In-Reply-To: <200408051702.NAA00063@ietf.org> Message-ID: References: <200408051702.NAA00063@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] About the Localized RSVP routing/adressing X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Hi, I guess my presentation, and the slide was misleading. The draft itself should give a better description of the issue of addressing and routing of the Path Request. I'll try to give a short summary here. When an end host sends a Path message, it knows the party it is making a reservation with, right? Let's say that end host Ahost with IP address A wants to make a reservation for a flow towards end host Bhost with IP address B. Ahost knows Bhost and will be able to set B as the destination of the Path message. For a downstream reservation for a flow coming from Bhost, if Ahost knows B, it doesn't matter whether Ahost sends a Path or a Path Request to trigger the "proxy" - Ahost will anyway use B as the destination of the message. The routing infrastructure will get the message to the proxy. The idea to have a separate message is that it makes the design clearly separate from standard RSVP. The Path and Path Request messages are identical in format, just the message type differs. Moreover, the Path Request is only needed once, for triggering the proxy. Further Path Requests may not be needed. So, the Path Request does not have as destination address the proxy's IP address - I guess this was not clear from my presentation. The interesting case is, whether Ahost could make a downstream reservation without knowing the sender? For example, set up a wildcard reservation for VoIP flows to certain ports regardless of the sender. In this case, Ahost needs an IP address for the trigger message, what ever the message type is. This is where, if such a feature is needed, we need to have some rules on how to address the trigger message. The draft suggests to use e.g. the address of the default router, which would be configured by the operator to know where the proxy is, or Ahost could have the address of the proxy configured automagically. I don't think the message type matters here, the question is how to address and route the trigger message. Thus, in summary, the basic case where Ahost knows Bhost for upstream and downstream reservations, there is no need for Ahost to know anything about the proxy, except that it is there, somewhere. I guess the general opinion was that something like this would be a good thing. NSIS has this, but will not be mature for quite some time. There were some comments for and against this spec. I'd like to know if, after reading the draft (it's not that long), people feel like this should go forward, or not. I'll be here in San Diego up to early Saturday morning, if someone wants to talk about this some more. Regards, Jukka _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 5 21:15: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 VAA01273; Thu, 5 Aug 2004 21:15:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BstO1-0001OS-2O; Thu, 05 Aug 2004 21:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BstId-0007c9-Kx; Thu, 05 Aug 2004 21:13:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BstD4-0006zh-ON for tsvwg@megatron.ietf.org; Thu, 05 Aug 2004 21:07:50 -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 VAA01050 for ; Thu, 5 Aug 2004 21:07:48 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BstGd-0001JN-1b for tsvwg@ietf.org; Thu, 05 Aug 2004 21:11:34 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7617dEP000802 for ; Thu, 5 Aug 2004 21:07:39 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Aug 2004 21:07:38 -0400 Message-ID: To: tsvwg@ietf.org Date: Thu, 5 Aug 2004 21:07:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.8.5.109751 X-PerlMx-Spam: Guage='%%XGUAGE%%%%IGUAGE%%', Probability='1%', Reasons='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0.000, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, EXCHANGE_SERVER 0, __HAS_X_MAILER 0, __IMS_MUA 0, __CT_TEXT_PLAIN 0, __CT 0, __PORN_PHRASE_15_0 0, __C230066_P2 0, __NEW_DOMAIN_EXTENSIONS_2 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Subject: [Tsvwg] Diffserv Basic Classes Draft Review X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Review of draft-baker-diffserv-basic-classes-03.txt Reviewer: David L. Black, EMC Corporation For the IETF Transport Area Working Group (tsvwg) August 5, 2004 ------------------------------------------------- -- Overall comment I had skimmed an earlier version of this draft and liked it. Having read this one in detail, I like it a *lot*. Diffserv has been described as a toolkit for constructing QoS services. This draft is like a set of project plans (or a do-it-yourself book on plumbing, wiring, etc.) that explains how to use the tools to build useful things in a fashion accessible to non-experts. This draft is a long-overdue addition to the set of diffserv documents, and does a nice job of weaving together the important elements of diffserv to show how they can be used together in useful ways. I'd like to be able say that those of us working on diffserv had such a coherent vision in mind from the beginning ... ;-). Most of these comments are details of various sorts. The important comments that affect content are: - Add top down traffic and application classification (Section 2.1). - Examples 2 and 3 need work (Section 2.2). - AF usage discussion cleanup [(a), (b), and (c) comments on Sections 4.3, 4.5, 4.7 and 4.8]. - Remove implied cap on Best Effort traffic (Section 4.9 - probably a typo/thinko, but an important one). - Enrich mapping discussion (Section 5 to the extent not covered by top down classification added to Section 2.1). -- Section 1.4.1 "with no further guarantees" is at odds with the recommendation in Section 4.9 that some minimum amount of bandwidth be guaranteed to best effort. Some sort of expectation that the network will be usable for best effort traffic (in some sense) is needed here. -- Section 2.1 Expand OAM acronym on first use. Mention of "(traditional telephony)" in description of signaling class is potentially confusing. Need to say that this signaling and control traffic *before* using the T-word. The network control traffic classes look good. For the user/subscriber classes, more in the way of top-down rough criteria for sorting traffic into classes would be a good addition. Figure 1 is a start, but aspects such as elasticity, burstiness, and whether the traffic is signaled seem to be collapsed into the description. I'm not sure whether another figure with lots of columns would be better. A couple of things should be added. First of all, a top-down description of how the traffic space is divided up that focuses on the traffic characteristics - in essence more structure in the center column in Figure 1. What I have in mind is almost there, but breaking out things like but elasticity, burstiness, and whether the traffic is signaled would probably help, although a 6+ column table is probably not what's needed. Second, a top down grouping the user/data classes into a smaller number of groups by application protocol type would help - to a first approximation, there are: - 5 media-oriented classes, split into Interactive (Telephony, Multimedia conferencing, RT Interactive) and Streaming (Multimedia, Broadcast Video) subgroups. - Signaling - 3 data classes (Low Latency, High Throughput, Low Priority), with Low Latency being Interactive, High Throughput being close to streaming (but more jitter-tolerant than media, plus TCP-like drop response), and Low Priority being Don't Care to some degree. - Standard (Best Effort) Signaling needs to be distinguished from Low Latency Data, as Signaling traffic *is* low latency data. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the (usually media) streams/sessions they signal and control. In Figure 3, add RFC references for the two 3-color markers. Last bullet in Section 2.1 needs to say "one of" the two services can be supported. If Low Priority data is mapped to 000xxx, recommend that xxx not be 000 to allow this to be distinguished from Standard. -- Section 2.2 Editing needed: A network administrator determined that they need There are a number of editing problems elsewhere - I didn't flag all of them. "Figure 4, provides a popular industry view" - What's a "popular industry view"? A different phrase should be used. Examples 2 & 3 - where did the numbers "five" and "eight" come from? Describing these networks in terms of traffic carried/services provided and the resulting differentiation goals would be better than picking numbers out of thin air. In general, these examples are short on detail/explanation. -- Section 3.2 In the past, I think routing has divided interior vs. exterior routing protocol traffic into CS7 vs. CS6. One of the implications of this draft appears to be that this approach is no longer recommended, [ ... snipped due to UPDATE ...] UPDATE: I'm informed by people who know better than I that routing does not use CS7, so it suffices to add routing to the list of traffic that is not appropriate for the Administrative Service class. Say how to distinguish Network Control signaling flows from user/subscriber signaling (this is not as easy as it looks, as it may depend on who owns the softswitch). -- Section 4.1 IP Telephony "MUST" use Telephony service class is at odds with the "SHOULD" for the list of protocols - either explain that the listed protocols can be used for services other than IP Telephony, or downgrade the "MUST" to a "SHOULD". o Packet flows from trusted sources (media gateways inside administered network) MAY not require policing. Can't say "MAY not", and that's also not quite right. Try "Policing is OPTIONAL for traffic from trusted sources whose behavior is assured via other means (e.g., administrative controls on those systems)." The text in the immediately following bullet has a better structure. -- Section 4.2 Explain "clipping". In essence, if the signaling protocol that sets up the connection fails to complete in the expected time, the result is audio loss/degradation at the start of the session, which is particularly noticeable when dealing with unforgiving POTS systems. How is "peer to peer real time control function" distinguished from low latency data? Data vs. control is fuzzy at best, so some discussion of what is controlled and/or the importance of the control function would help. -- Section 4.3 In first paragraph, expand "Video conferencing" example to "Audio and video conferencing". (a) If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point MUST perform Multifield (MF) Classification as defined in [RFC2475] and mark all packets as AF41. That's peculiar - it looks like it assumes the end-point stays inside the rate "A" profile/envelope, unless I missed something. Was AF4x intended instead of AF41? (b) Just to complicate things - running trTCM in Color-Aware mode assumes that "A" and "B" don't change across domain boundaries. If they do, Color-Blind may be necessary if the trTCM rates or burst sizes increase significantly in the direction of flow (else get too much red & yellow traffic, by comparison to traffic coming in on interfaces with trTCM running Color-Blind). (c) Should say something about use or non-use of marking to distinguish application-defined content layers in a single [media] stream (e.g., complete frames vs. delta frames, additional data for higher resolution). IMHO, history reveals this example to be an attractive nuisance (intellectually appealing, but unworkable in practice due to dynamic variation in codec output rates) and hence ought to carry a "SHOULD NOT" recommendation to disfavor it by comparison to the straight application-level-unaware rate-metering described here. -- Section 4.5 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF3* for any AF4* occurrences in those comments). -- Section 4.7 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF2* for any AF4* occurrences in those comments and likewise substitute srTCM for trTCM). -- Section 4.8 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF1* for any AF4* occurrences in those comments). -- Section 4.9 SHOULD be configured to receive a small percentage of forwarding resources (at least 5%). That can't what was intended, as it places a cap on best effort bandwidth. Remove the cap by doing something like inserting "at least" before "a small percentage" and adding "as a guaranteed minimum" at the end. I suspect this is a typo/thinko/oversight. -- Section 5 In general, this section should be enriched/extended, and in particular: - Please add a VPN service mapping discussion. - A discussion of mapping media flows (audio and/or video) should go here, unless it's covered by the discussion requested in Section 2.1 - Please add a summary of the UMTS traffic class mappings. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 6 00:15:52 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 AAA11748; Fri, 6 Aug 2004 00:15:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswCi-0004Yf-5O; Fri, 06 Aug 2004 00:19:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsw4q-0003Ta-7r; Fri, 06 Aug 2004 00:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsvxh-0001vz-R5 for tsvwg@megatron.ietf.org; Fri, 06 Aug 2004 00:04: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 AAA10535 for ; Fri, 6 Aug 2004 00:04:06 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsw1J-0004Ey-Qs for tsvwg@ietf.org; Fri, 06 Aug 2004 00:07:55 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7643Tj16454; Fri, 6 Aug 2004 00:03:30 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPXPAYSQ; Fri, 6 Aug 2004 00:03:29 -0400 Received: from KCHAN-2K3.nortelnetworks.com (asc3t09j.us.nortel.com [47.81.8.61]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSKYPZQT; Fri, 6 Aug 2004 00:03:28 -0400 Message-Id: <6.0.3.0.0.20040805235744.043470d0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 06 Aug 2004 00:03:25 -0400 To: tsvwg@ietf.org From: Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Jozef Z Babiarz , Kwok Ho Chan , Fred Baker , jon.peterson@neustar.biz, mankin@psg.com Subject: [Tsvwg] DiffServ Service Classes Slides presented in TSVWG @ 60th IETF X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Please find at: ftp://standards.nortelnetworks.com/diffserv/DiffServ_BasicClasses_60thIETF.ppt the slides for the DiffServ Basic Classes draft presentation at the TSVWG WG at 60th IETF @ San Diego. Please also use this for the Proceedings. Thank you! -- Kwok Ho Chan -- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 6 00: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 AAA12319; Fri, 6 Aug 2004 00:21:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswI0-0004iG-5D; Fri, 06 Aug 2004 00:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsw9d-0005Oc-Cx; Fri, 06 Aug 2004 00:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsw5n-0003ny-Qy for tsvwg@megatron.ietf.org; Fri, 06 Aug 2004 00:12: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 AAA11361 for ; Fri, 6 Aug 2004 00:12:28 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsw9P-0004SV-Tb for tsvwg@ietf.org; Fri, 06 Aug 2004 00:16:17 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i764BwU15565 for ; Fri, 6 Aug 2004 00:11:58 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Aug 2004 00:11:58 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465D87DCA@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: tsvwg@ietf.org Date: Fri, 6 Aug 2004 00:11:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Tsvwg] Slides on ECN for real-time traffic X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0910870938==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0910870938== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47B6B.828AFD80" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C47B6B.828AFD80 Content-Type: text/plain Here is the link to slide that were presented today at tsvwg. ftp://standards.nortelnetworks.com/diffserv/rtecn-01.ppt Regards, Joe. Jozef Babiarz ------_=_NextPart_001_01C47B6B.828AFD80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Slides on ECN for real-time traffic

Here is = the  link to slide = that were presented today at = tsvwg.

ftp://standards.nortelnetworks.com/diffserv/rtecn-01.ppt

Regards, = Joe.

Jozef = Babiarz

------_=_NextPart_001_01C47B6B.828AFD80-- --===============0910870938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0910870938==-- From tsvwg-bounces@ietf.org Fri Aug 6 00:33: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 AAA13283; Fri, 6 Aug 2004 00:33:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswTm-0004wk-Bj; Fri, 06 Aug 2004 00:37:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BswOW-0007yO-Qn; Fri, 06 Aug 2004 00:31:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BswK1-0007Ry-89 for tsvwg@megatron.ietf.org; Fri, 06 Aug 2004 00:27:13 -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 AAA12883 for ; Fri, 6 Aug 2004 00:27:09 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswNd-0004q6-Df for tsvwg@ietf.org; Fri, 06 Aug 2004 00:30:58 -0400 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 06 Aug 2004 07:27:05 +0300 Date: Fri, 6 Aug 2004 07:27:04 +0300 (EEST) From: Jukka MJ Manner To: tsvwg@ietf.org In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465D87DCA@zcarhxm1.corp.nortel.com> Message-ID: References: <9671A92C3C8B5744BC97F855F7CB6465D87DCA@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Slides on Localized RSVP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit My slides from this morning can be found at: http://www.cs.helsinki.fi/u/jmanner/lrsvp_ietf60.pdf Jukka _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 6 00:53:25 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 AAA14476; Fri, 6 Aug 2004 00:53:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bswn1-0005Il-Rr; Fri, 06 Aug 2004 00:57:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BswZw-0001Dl-1G; Fri, 06 Aug 2004 00:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BswWF-0000eb-MM for tsvwg@megatron.ietf.org; Fri, 06 Aug 2004 00:39:51 -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 AAA13673 for ; Fri, 6 Aug 2004 00:39:48 -0400 (EDT) Received: from zsc3s004.nortelnetworks.com ([47.81.138.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswZp-00053W-MS for tsvwg@ietf.org; Fri, 06 Aug 2004 00:43:37 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i764dAV03802 for ; Thu, 5 Aug 2004 21:39:10 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T6BK0; Thu, 5 Aug 2004 21:38:21 -0700 Received: from KCHAN-2K3.nortelnetworks.com (asc3t09j.us.nortel.com [47.81.8.61]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSKYPZQ8; Fri, 6 Aug 2004 00:38:20 -0400 Message-Id: <6.0.3.0.0.20040806003230.03f471b8@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 06 Aug 2004 00:38:17 -0400 To: tsvwg@ietf.org From: Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Tsvwg] DiffServ Service Classes Slides presented in TSVWG @ 60th IETF X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Please find at: ftp://standards.nortelnetworks.com/diffserv/DiffServ_BasicClasses_60thIETF.ppt the slides for the DiffServ Basic Classes draft presentation at the TSVWG WG at 60th IETF @ San Diego. Please also use this for the Proceedings. Thank you! -- Kwok Ho Chan -- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 6 14:28:36 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 OAA15698; Fri, 6 Aug 2004 14:28:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt9Vw-0002aL-Om; Fri, 06 Aug 2004 14:32:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt9PQ-0003Ka-2k; Fri, 06 Aug 2004 14:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt9IW-0002Mc-0O for tsvwg@megatron.ietf.org; Fri, 06 Aug 2004 14:18:32 -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 OAA15205 for ; Fri, 6 Aug 2004 14:18:30 -0400 (EDT) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt9MF-0002OG-IZ for tsvwg@ietf.org; Fri, 06 Aug 2004 14:22:24 -0400 Received: from emss04g01.ems.lmco.com (relay4.ems.lmco.com [166.17.13.122]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id i76IGWkc014134; Fri, 6 Aug 2004 14:16:35 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30884) id <0I2100M01ERKO9@lmco.com>; Fri, 06 Aug 2004 14:16:32 -0400 (EDT) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1X6 #30884) with ESMTP id <0I2100HAKERJE6@lmco.com>; Fri, 06 Aug 2004 14:16:32 -0400 (EDT) Received: from EMSS04M14.us.lmco.com ([162.16.20.50]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 06 Aug 2004 14:16:30 -0400 Date: Fri, 06 Aug 2004 14:16:30 -0400 From: "Bose, Pratik" To: "James M. Polk" , tsvwg , sdhesika@cisco.com Message-id: <37B6F612D86CA143B5F965E9EE8BD7AA0798B29D@emss04m14.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: RESV_TEAR Inclusion in draft-reduction Thread-Index: AcR2op9zOeAu24GQT/698G9pPgHmdgFPMTog content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Aug 2004 18:16:30.0790 (UTC) FILETIME=[7F5D5E60:01C47BE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT Subject: [Tsvwg] RESV_TEAR Inclusion in draft-reduction X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7BIT James and Subha, Since you did present that in the next rev, you want to include the tear message, here are some aspects for your consideration When the preemption is going to occur in favor of a new highest precedence reservation, capability for tearing down the reservation either immediately or within a configurable timeout can admit the rare, emergency call quickly. Also you seem to have already thought of this - a tear would keep the current rsvp mechanism of tearing the reservation still in place, and the tear also seems to be required for the error condition when the resv_err gets lost etc. Thanks, Pratik > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > On Behalf Of James M. Polk > Sent: Friday, July 30, 2004 9:53 PM > To: tsvwg > Subject: [Tsvwg] Is there an Agenda posted for the TSVWG meeting? > > Hey > > Just wondering if there was an agenda posted that I can review... > > Thanks > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Aug 11 14:31:35 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 OAA24739; Wed, 11 Aug 2004 14:31:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buxxh-0004ib-Rn; Wed, 11 Aug 2004 14:36:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buxrc-0004Uo-OE; Wed, 11 Aug 2004 14:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxkH-0002xs-EU for tsvwg@megatron.ietf.org; Wed, 11 Aug 2004 14:22:41 -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 OAA24056 for ; Wed, 11 Aug 2004 14:22:40 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buxp1-0004Uf-UL for tsvwg@ietf.org; Wed, 11 Aug 2004 14:27:39 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 955AD7176 for ; Wed, 11 Aug 2004 11:30:34 -0700 (PDT) To: tsvwg@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Wed, 11 Aug 2004 11:22:06 -0700 From: Eric Rescorla Message-Id: <20040811183034.955AD7176@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Tsvwg] Looking for feedback on DTLS X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a As we all know, TLS is popular but is only compatible with reliable transports. Unfortunately, a number of important protocols (SIP in particular) run over datagram transport and therefore cannot use TLS. In response, Nagendra Modadugu and I have designed a variant of TLS which we call Datagram TLS (DTLS). DTLS consists of only the minimal changes required to TLS to make it operate on datagram transport. We've submitted DTLS as an I-D which you can find at: draft-rescorla-dtls-01.txt You can also read our paper on DTLS from ISOC NDSS at: http://crypto.stanford.edu/~nagendra/papers/dtls.pdf We've already gotten some useful comments from PMTUD people about handling PMTU but any comments TSV people have on the protocol would be appreciated. Best, -Ekr _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Aug 11 17:04:27 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 RAA16767; Wed, 11 Aug 2004 17:04:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv0Ld-0002nQ-Lc; Wed, 11 Aug 2004 17:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buymg-00009x-Qk; Wed, 11 Aug 2004 15:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buyhp-0005cM-3Q for tsvwg@megatron.ietf.org; Wed, 11 Aug 2004 15:24:13 -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 PAA01291 for ; Wed, 11 Aug 2004 15:24:11 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buymc-0006AZ-2E for tsvwg@ietf.org; Wed, 11 Aug 2004 15:29:11 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id DBCED7177 for ; Wed, 11 Aug 2004 12:32:07 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id A784344AB0; Wed, 11 Aug 2004 12:23:39 -0700 (PDT) To: tsvwg@ietf.org Subject: Re: [Tsvwg] Looking for feedback on DTLS References: <20040811183034.955AD7176@sierra.rtfm.com> From: Eric Rescorla Date: Wed, 11 Aug 2004 12:23:39 -0700 In-Reply-To: <20040811183034.955AD7176@sierra.rtfm.com> (Eric Rescorla's message of "Wed, 11 Aug 2004 11:22:06 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Reasonable Discussion, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Eric Rescorla writes: > As we all know, TLS is popular but is only compatible with reliable > transports. Unfortunately, a number of important protocols (SIP in > particular) run over datagram transport and therefore cannot use TLS. This was bad writing on my part: Obviously, SIP *can* use TCP and when it's operating in TCP mode it can use TLS. However, SIP can also operate in UDP mode and in those situations one obviously cannot use TLS. In my conversations with SIP people, it's been my understanding that there are situations in which they would like to be able to UDP, but that that comes into conflict with the desire to use TLS. DTLS is designed to address that need. If I've misunderstood and that's not the situation, I trust someone will correct me. Sorry for the confusion. -Ekr _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 12 03:35: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 DAA09469; Thu, 12 Aug 2004 03:35:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvACA-0005rv-OI; Thu, 12 Aug 2004 03:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvA3L-0004KG-AU; Thu, 12 Aug 2004 03:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv9w0-0002rw-3O for tsvwg@megatron.ietf.org; Thu, 12 Aug 2004 03:23:36 -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 DAA08832 for ; Thu, 12 Aug 2004 03:23:34 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvA0e-0005em-60 for tsvwg@ietf.org; Thu, 12 Aug 2004 03:28:41 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i7C7NH4e018603; Thu, 12 Aug 2004 00:23:17 -0700 (MST) Received: from motorola.com ([163.14.20.41]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7C7FTQ1003516; Thu, 12 Aug 2004 02:15:30 -0500 Message-ID: <411B1521.6040108@motorola.com> Date: Thu, 12 Aug 2004 14:58:41 +0800 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [Tsvwg] Looking for feedback on DTLS References: <20040811183034.955AD7176@sierra.rtfm.com> In-Reply-To: <20040811183034.955AD7176@sierra.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Eric, Would DTLS also render support to the un-ordered and partial reliability SCTP data transfer? regards, -Qiaobing Eric Rescorla wrote: > As we all know, TLS is popular but is only compatible with reliable > transports. Unfortunately, a number of important protocols (SIP in > particular) run over datagram transport and therefore cannot use TLS. In > response, Nagendra Modadugu and I have designed a variant of TLS which > we call Datagram TLS (DTLS). DTLS consists of only the minimal changes > required to TLS to make it operate on datagram transport. > > We've submitted DTLS as an I-D which you can find at: > draft-rescorla-dtls-01.txt > > You can also read our paper on DTLS from ISOC NDSS at: > http://crypto.stanford.edu/~nagendra/papers/dtls.pdf > > We've already gotten some useful comments from PMTUD people about > handling PMTU but any comments TSV people have on the protocol would be > appreciated. > > Best, > -Ekr > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 12 11:12:06 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 LAA08024; Thu, 12 Aug 2004 11:12:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvHKP-0005oA-NV; Thu, 12 Aug 2004 11:17:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvH27-0005vr-5s; Thu, 12 Aug 2004 10:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGxg-0004j8-Dc for tsvwg@megatron.ietf.org; Thu, 12 Aug 2004 10:53: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 KAA06651 for ; Thu, 12 Aug 2004 10:53:46 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvH2e-0005MB-0P for tsvwg@ietf.org; Thu, 12 Aug 2004 10:58:57 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 01A7B719B; Thu, 12 Aug 2004 08:01:44 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 93D2B44AB0; Thu, 12 Aug 2004 07:53:14 -0700 (PDT) To: Qiaobing Xie Subject: Re: [Tsvwg] Looking for feedback on DTLS References: <20040811183034.955AD7176@sierra.rtfm.com> <411B1521.6040108@motorola.com> From: Eric Rescorla Date: Thu, 12 Aug 2004 07:53:14 -0700 In-Reply-To: <411B1521.6040108@motorola.com> (Qiaobing Xie's message of "Thu, 12 Aug 2004 14:58:41 +0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Reasonable Discussion, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Qiaobing Xie writes: > Would DTLS also render support to the un-ordered and partial > reliability SCTP data transfer? Yes. That said, Michael Tuexen and Randall Stewart have both pointed out to me that as SCTP provides better information/guarantees in some cases, you could probably get away without some of the DTLS machinery, but I'm not sure that that would be that useful an optimization at the end of the day. Cheers, -Ekr _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 13 12:33:56 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 MAA27186; Fri, 13 Aug 2004 12:33:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvf5L-0001jO-9c; Fri, 13 Aug 2004 12:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvern-0008LD-3t; Fri, 13 Aug 2004 12:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvedq-0003WK-Hb for tsvwg@megatron.ietf.org; Fri, 13 Aug 2004 12:10:54 -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 MAA25684 for ; Fri, 13 Aug 2004 12:10:51 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvej0-0001HE-01 for tsvwg@ietf.org; Fri, 13 Aug 2004 12:16:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2004 09:14:36 +0000 X-BrightmailFiltered: true 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 i7DG9ucx001672; Fri, 13 Aug 2004 09:10:17 -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 JAA24655; Fri, 13 Aug 2004 09:09:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20040813111007.0310a190@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Aug 2004 11:10:41 -0500 To: "Bose, Pratik" , tsvwg , sdhesika@cisco.com From: "James M. Polk" In-Reply-To: <37B6F612D86CA143B5F965E9EE8BD7AA0798B29D@emss04m14.us.lmco .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Tsvwg] Re: RESV_TEAR Inclusion in draft-reduction X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Pratik I would agree with all you state below At 02:16 PM 8/6/2004 -0400, Bose, Pratik wrote: >James and Subha, > >Since you did present that in the next rev, you want to include the tear >message, here are some aspects for your consideration > >When the preemption is going to occur in favor of a new highest >precedence reservation, capability for tearing down the reservation >either immediately or within a configurable timeout can admit the rare, >emergency call quickly. > >Also you seem to have already thought of this - a tear would keep the >current rsvp mechanism of tearing the reservation still in place, and >the tear also seems to be required for the error condition when the >resv_err gets lost etc. > >Thanks, > >Pratik > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > > On Behalf Of James M. Polk > > Sent: Friday, July 30, 2004 9:53 PM > > To: tsvwg > > Subject: [Tsvwg] Is there an Agenda posted for the TSVWG meeting? > > > > Hey > > > > Just wondering if there was an agenda posted that I can review... > > > > Thanks > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Aug 19 07:53:13 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 HAA24066; Thu, 19 Aug 2004 07:53:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxlaC-0001wU-58; Thu, 19 Aug 2004 07:59:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxlRe-0003hP-UX; Thu, 19 Aug 2004 07:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxlPq-0003Ls-Lk for tsvwg@megatron.ietf.org; Thu, 19 Aug 2004 07:49: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 HAA23904 for ; Thu, 19 Aug 2004 07:49:09 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxlWF-0001tH-Bd for tsvwg@ietf.org; Thu, 19 Aug 2004 07:55:48 -0400 Received: from [192.168.1.22] (p5089FD4D.dip.t-dialin.net [80.137.253.77]) by ilsa.franken.de (Postfix) with ESMTP id BC909245C5; Thu, 19 Aug 2004 13:49:05 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: <20040811183034.955AD7176@sierra.rtfm.com> <411B1521.6040108@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] Looking for feedback on DTLS Date: Thu, 19 Aug 2004 13:48:55 +0200 To: EKR X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Qiaobing Xie X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Dear Qiaobing, Dear Eric, I think it is necessary to have a version of TLS which - supports all SCTP features including PR-SCTP - is implementable within the openssl library The current method of TLS over SCTP does not support 'out of order delivery' and PR-SCTP. The other problem is that it uses a TLS connection for each bidirectional stream. This is difficult to implement in openssl, because you do not have a socket per stream. So I thought about a modified version of TLS and talked to Eric at the last IETF. His suggestion was to simply use DTLS. I'm just looking at that and trying to understand DTLS. The first point is to figure out if it works and the second is if there are some optimizations. Eric, here is one question for you: You increment the epoch field with each cipher state change. So I assume that a receiver has a state describing the current epoch, right? How are packets handled which are received with an epoch less than the current one? Do you discard that packet or do you have also the old state available to process it? Best regards Michael On Aug 12, 2004, at 4:53 PM, Eric Rescorla wrote: > Qiaobing Xie writes: >> Would DTLS also render support to the un-ordered and partial >> reliability SCTP data transfer? > > Yes. > > That said, Michael Tuexen and Randall Stewart have both pointed out > to me that as SCTP provides better information/guarantees in some > cases, you could probably get away without some of the DTLS machinery, > but I'm not sure that that would be that useful an optimization > at the end of the day. > > Cheers, > -Ekr > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Aug 23 14:18:02 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 OAA28143; Mon, 23 Aug 2004 14:18:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzJOj-0002JE-Q8; Mon, 23 Aug 2004 14:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzJ0n-0000cp-GC; Mon, 23 Aug 2004 13:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIiD-0006WO-Ki for tsvwg@megatron.ietf.org; Mon, 23 Aug 2004 13:34: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 NAA25008 for ; Mon, 23 Aug 2004 13:34:23 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzIiP-0001SV-Qv for tsvwg@ietf.org; Mon, 23 Aug 2004 13:34:46 -0400 Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7NHY9B26436 for ; Mon, 23 Aug 2004 10:34:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: tsvwg@ietf.org From: Aaron Falk Date: Mon, 23 Aug 2004 10:34:04 -0700 X-Mailer: Apple Mail (2.619) X-ISI-4-32-5-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] DCCP spec & congestion control profiles in working group last call X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi- This is a heads up that the Datagram Congestion Control Working Group is last calling a new transport protocol (DCCP) for Proposed Standard. There are three documents (noted below) and discussion is, naturally, on the DCCP mailing list. WG charter and mail list info can be found at http://www.ietf.org/html.charters/dccp-charter.html. Regards, --aaron Begin forwarded message: > From: Aaron Falk > Date: August 18, 2004 10:54:25 AM PDT > To: dccp@ietf.org > Cc: Allison Mankin > Subject: [dccp] working group last call extension > > Hi- > > I've had a request to extend last call by a week to enable additional > review. So, last call will be ending on August 27th. > > Also, while there have been some good comments on the spec, I'm not > seeing any indication that people are reading the CCIDs. So, please > review them as they are also up for Proposed Standard. > > Finally, even if you have no criticisms of these documents, it is > helpful to know that they have been reviewed. Notes indicating > support for the protocol to advance are welcome. > > --aaron > > > > Begin forwarded message: > >> From: Aaron Falk >> Date: July 20, 2004 1:15:24 PM PDT >> To: dccp@ietf.org >> Cc: Eddie Kohler , Sally Floyd , >> Mark Handley , Allison Mankin >> >> Subject: [dccp] Working Group Last Call for DCCP spec, ccid2, ccid3 >> >> All- >> >> This is to kick off the wglc for the DCCP core documents: >> >> Datagram Congestion Control Protocol (DCCP) >> http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-07.txt >> >> Profile for DCCP Congestion Control ID 2: TCP-like Congestion >> Control >> http://www.ietf.org/internet-drafts/draft-ietf-dccp-ccid3-06.txt >> >> Profile for DCCP Congestion Control ID 3: TFRC Congestion Control >> http://www.ietf.org/internet-drafts/draft-ietf-dccp-ccid2-06.txt >> >> Since the last call is starting right before the IETF-60 meeting, we >> will extend it to conclude August 20th. Discussion of last call >> comments will be on the agenda for the DCCP session at IETF-60. >> >> Please use helpful subject lines in your comments. For example, >> "Concerns about the scalability of the foo exchange" is better than >> "My thoughts on DCCP". Also, specific proposed changes are better >> than "I don't like this." >> >> Many thanks, >> >> --aaron (DCCP wg chair) >> >> > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 27 05:47:01 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 FAA14719; Fri, 27 Aug 2004 05:47:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0dLB-0005Nb-Dd; Fri, 27 Aug 2004 05:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0dIX-0007FL-RC; Fri, 27 Aug 2004 05:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0dHv-00071x-44 for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 05:44:51 -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 FAA14365 for ; Fri, 27 Aug 2004 05:44:48 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0dJ1-0005Gb-G8 for tsvwg@ietf.org; Fri, 27 Aug 2004 05:46:00 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7R9iF1t006299 for ; Fri, 27 Aug 2004 04:44:17 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id PAA16697; Fri, 27 Aug 2004 15:06:14 -0500 (GMT) Message-ID: <412F0387.1010001@axesb2.usa.alcatel.com> Date: Fri, 27 Aug 2004 15:18:55 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP-Processing of bundled abort chunk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi Regarding the processing of an ABORT chunk bundled with other control chunks, the following sections of RFC 2960 are somewhat conflicting: The section 3.3.7 says: "Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be placed before the ABORT in the SCTP packet, or they will be ignored by the receiver." It means that the chunks bundled before ABORT chunk should be processed. But the Section 9.1 says: "An endpoint MUST NOT respond to any received packet that contains an Abort chunk". Again the Section 6.10 says: "An endpoint MUST process received chunks in their order in the packet". Can anybody guide us in this regard. Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 27 06:38: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 GAA17522; Fri, 27 Aug 2004 06:38:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0e8b-0006Ir-5S; Fri, 27 Aug 2004 06:39:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0e0w-0008Os-Su; Fri, 27 Aug 2004 06:31:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0dyV-0007y1-Lf for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 06:28:52 -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 GAA17038 for ; Fri, 27 Aug 2004 06:28:48 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[0Lxt2/EMlaS0SQm0jCFSfQgUQI2sW8NC]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0dza-00069a-E3 for tsvwg@ietf.org; Fri, 27 Aug 2004 06:30:01 -0400 Received: from ns.pigworks.openss7.net (IDENT:CgAs9hlw6rEquUIHJFGmtYnA95rW+eN3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i7RASkQ04625; Fri, 27 Aug 2004 04:28:46 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i7RASjB12422; Fri, 27 Aug 2004 04:28:45 -0600 Date: Fri, 27 Aug 2004 04:28:45 -0600 From: "Brian F. G. Bidulock" To: bhanu Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk Message-ID: <20040827042845.A11286@openss7.org> References: <412F0387.1010001@axesb2.usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <412F0387.1010001@axesb2.usa.alcatel.com>; from bprakash@axesb2.usa.alcatel.com on Fri, Aug 27, 2004 at 03:18:55PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id i7RASkQ04625 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable bhanu, On Fri, 27 Aug 2004, bhanu wrote: > Hi >=20 > Regarding the processing of an ABORT chunk bundled with other control=20 > chunks, > the following sections of RFC 2960 are somewhat conflicting: >=20 > The section 3.3.7 says: > "Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) > MAY be bundled with an ABORT but they MUST be placed before the ABORT > in the SCTP packet, or they will be ignored by the receiver." > It means that the chunks bundled before ABORT chunk should be processed. >=20 > But the Section 9.1 says: > "An endpoint MUST NOT respond to any received packet that contains an=20 > Abort chunk". This says that the endpoint must not _respond_ it doesn't say that the chunks ahead of the ABORT are not processed. --brian >=20 > Again the Section 6.10 says: >=20 > "An endpoint MUST process received chunks in their order in the packet". >=20 > Can anybody guide us in this regard. >=20 > Regards > Bhanu. >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 27 06:58:32 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 GAA18925; Fri, 27 Aug 2004 06:58:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0eSN-0006j3-0P; Fri, 27 Aug 2004 06:59:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eHU-0002sg-1V; Fri, 27 Aug 2004 06:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eFE-0002LE-M8; Fri, 27 Aug 2004 06:46:08 -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 GAA18230; Fri, 27 Aug 2004 06:46:05 -0400 (EDT) Received: from mail16.messagelabs.com ([64.124.170.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C0eGM-0006TM-La; Fri, 27 Aug 2004 06:47:18 -0400 X-VirusChecked: Checked X-Env-Sender: Sonali.Francis@lntinfotech.com X-Msg-Ref: server-23.tower-16.messagelabs.com!1093603534!5548629 X-StarScan-Version: 5.2.11; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 21767 invoked from network); 27 Aug 2004 10:45:34 -0000 Received: from bangaloresmtp.lntinfotech.com (203.101.96.4) by server-23.tower-16.messagelabs.com with SMTP; 27 Aug 2004 10:45:34 -0000 Received: from bangalore1.lntinfotech.com ([172.29.20.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004082716143304:62185 ; Fri, 27 Aug 2004 16:14:33 +0530 Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk To: bhanu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Sonali Francis" Date: Fri, 27 Aug 2004 16:15:54 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE1/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 08/27/2004 04:15:55 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 08/27/2004 04:14:33 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 08/27/2004 04:14:34 PM, Serialize complete at 08/27/2004 04:14:34 PM Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tsvwg@ietf.org, tsvwg-bounces@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Dear Bhanu, As per the RFC, the sender of ABORT should consider following points: 1. While sending ABORT, control chunks other than INIT, INIT ACK and SHUTDOWN COMPLETE can be bundled with it. 2. While sending ABORT, DATA chunk is not to be bundled with it. 3. While bundling ABORT with any other control chunk, the ABORT to be placed at the end. At the receiving end, while processing any chunk containing ABORT, the receiver should do the following: 1.If the first chunk is ABORT, process it and then ignore rest of the chunks in the packet. 2.If the last chunk is ABORT, then process other control chunks, but do not respond. Here the next obvious question may be, what if the sender of control chunks, bundled with ABORT needs a response back. But, can you identify any such scenario? In my opinion, there wont be any such situation where the sender of ABORT need any response back other than aborting the association. Regards, Sonali bhanu cc: Sent by: Subject: [Tsvwg] SCTP-Processing of bundled abort chunk tsvwg-bounces@ietf.org 08/27/2004 03:18 PM Hi Regarding the processing of an ABORT chunk bundled with other control chunks, the following sections of RFC 2960 are somewhat conflicting: The section 3.3.7 says: "Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be placed before the ABORT in the SCTP packet, or they will be ignored by the receiver." It means that the chunks bundled before ABORT chunk should be processed. But the Section 9.1 says: "An endpoint MUST NOT respond to any received packet that contains an Abort chunk". Again the Section 6.10 says: "An endpoint MUST process received chunks in their order in the packet". Can anybody guide us in this regard. Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ______________________________________________________________________ ______________________________________________________________________ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 27 07:10:29 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 HAA19758; Fri, 27 Aug 2004 07:10:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0edy-0006zR-LA; Fri, 27 Aug 2004 07:11:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eWZ-0005k0-Mm; Fri, 27 Aug 2004 07:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eOm-00048n-LK for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 06:56: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 GAA18831 for ; Fri, 27 Aug 2004 06:55:57 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ePu-0006g2-FP for tsvwg@ietf.org; Fri, 27 Aug 2004 06:57:10 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7RAtPDE022008; Fri, 27 Aug 2004 05:55:26 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id QAA16815; Fri, 27 Aug 2004 16:17:23 -0500 (GMT) Message-ID: <412F1434.7090508@axesb2.usa.alcatel.com> Date: Fri, 27 Aug 2004 16:30:04 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk References: <412F0387.1010001@axesb2.usa.alcatel.com> <20040827042845.A11286@openss7.org> X-Spam-Score: 0.5 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295811285==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 --===============0295811285== Content-Type: multipart/alternative; boundary="------------080706030503070609000106" --------------080706030503070609000106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi If a control chunk (for example the COOKIE ECHO chunk) is bundled (before)with ABORT what should be the response from the receiver of the bundled packet...??? (As per you it should not respond..!!!!!) Thanks Bhanu.. Brian F. G. Bidulock wrote: >bhanu, > >On Fri, 27 Aug 2004, bhanu wrote: > > > >>Hi >> >>Regarding the processing of an ABORT chunk bundled with other control >>chunks, >>the following sections of RFC 2960 are somewhat conflicting: >> >>The section 3.3.7 says: >>"Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) >> MAY be bundled with an ABORT but they MUST be placed before the ABORT >> in the SCTP packet, or they will be ignored by the receiver." >>It means that the chunks bundled before ABORT chunk should be processed. >> >>But the Section 9.1 says: >>"An endpoint MUST NOT respond to any received packet that contains an >>Abort chunk". >> >> > >This says that the endpoint must not _respond_ it doesn't say that the >chunks ahead of the ABORT are not processed. > >--brian > > > >>Again the Section 6.10 says: >> >>"An endpoint MUST process received chunks in their order in the packet". >> >>Can anybody guide us in this regard. >> >>Regards >>Bhanu. >> >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > > --------------080706030503070609000106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

If a control chunk (for example the COOKIE ECHO chunk) is bundled (before)with ABORT
what should be the response from the receiver of the bundled packet...???
(As per you it should not respond..!!!!!)

Thanks
Bhanu..

Brian F. G. Bidulock wrote:
bhanu,

On Fri, 27 Aug 2004, bhanu wrote:

  
Hi

Regarding the processing of an ABORT chunk bundled with other control 
chunks,
the following sections of RFC 2960 are somewhat conflicting:

The section 3.3.7 says:
"Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE)
 MAY be bundled with an ABORT but they MUST be placed before the ABORT
 in the SCTP packet, or they will be ignored by the receiver."
It means that the chunks bundled before ABORT chunk should be processed.

But the Section 9.1 says:
"An endpoint MUST NOT respond to any received packet that contains an 
Abort chunk".
    

This says that the endpoint must not _respond_ it doesn't say that the
chunks ahead of the ABORT are not processed.

--brian

  
Again the Section 6.10 says:

"An endpoint MUST process received chunks in their order in the packet".

Can anybody guide us in this regard.

Regards
Bhanu.


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

--------------080706030503070609000106-- --===============0295811285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0295811285==-- From tsvwg-bounces@ietf.org Fri Aug 27 08:31:22 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 IAA24985; Fri, 27 Aug 2004 08:31:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0fuF-0000As-7p; Fri, 27 Aug 2004 08:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fia-0003FK-7r; Fri, 27 Aug 2004 08:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fay-0001jn-ND for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 08:12: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 IAA23812 for ; Fri, 27 Aug 2004 08:12:39 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[v4usMO0hCNEhITAjqWg4nCE4gxKQTSwb]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0fc7-0008Hv-EJ for tsvwg@ietf.org; Fri, 27 Aug 2004 08:13:51 -0400 Received: from ns.pigworks.openss7.net (IDENT:chGzoj1J2ZFqI9bbugkq6bWa5ucPkR/e@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i7RCCdQ06640; Fri, 27 Aug 2004 06:12:39 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i7RCCc613746; Fri, 27 Aug 2004 06:12:38 -0600 Date: Fri, 27 Aug 2004 06:12:38 -0600 From: "Brian F. G. Bidulock" To: bhanu Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk Message-ID: <20040827061238.A13333@openss7.org> References: <412F0387.1010001@axesb2.usa.alcatel.com> <20040827042845.A11286@openss7.org> <412F1434.7090508@axesb2.usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <412F1434.7090508@axesb2.usa.alcatel.com>; from bprakash@axesb2.usa.alcatel.com on Fri, Aug 27, 2004 at 04:30:04PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id i7RCCdQ06640 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable bhanu, > But the Section 9.1 says: > "An endpoint MUST NOT respond to any received packet that contains an=20 > Abort chunk". Why do you think COOKIE ECHO is special? --brian On Fri, 27 Aug 2004, bhanu wrote: >=20 > Hi > If a control chunk (for example the COOKIE ECHO chunk) is bundl= ed > (before)with ABORT > what should be the response from the receiver of the bundl= ed > packet...??? > (As per you it should not respond..!!!!!) > Thanks > Bhanu.. > Brian F. G. Bidulock wrote: >=20 > bhanu, >=20 > On Fri, 27 Aug 2004, bhanu wrote: >=20 > =20 >=20 > Hi >=20 > Regarding the processing of an ABORT chunk bundled with other control=20 > chunks, > the following sections of RFC 2960 are somewhat conflicting: >=20 > The section 3.3.7 says: > "Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) > MAY be bundled with an ABORT but they MUST be placed before the ABORT > in the SCTP packet, or they will be ignored by the receiver." > It means that the chunks bundled before ABORT chunk should be processed. >=20 > But the Section 9.1 says: > "An endpoint MUST NOT respond to any received packet that contains an=20 > Abort chunk". > =20 >=20 > This says that the endpoint must not _respond_ it doesn't say that the > chunks ahead of the ABORT are not processed. >=20 > --brian >=20 > =20 >=20 > Again the Section 6.10 says: >=20 > "An endpoint MUST process received chunks in their order in the packet". >=20 > Can anybody guide us in this regard. >=20 > Regards > Bhanu. >=20 >=20 > _______________________________________________ > tsvwg mailing list > [1]tsvwg@ietf.org > [2]https://www1.ietf.org/mailman/listinfo/tsvwg >=20 > References >=20 > 1. mailto:tsvwg@ietf.org > 2. https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Aug 27 09:20:58 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 JAA27925; Fri, 27 Aug 2004 09:20:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ggF-000180-NG; Fri, 27 Aug 2004 09:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gWp-0004sG-Ux; Fri, 27 Aug 2004 09:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gOS-0002x1-RR for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 09:03: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 JAA26861 for ; Fri, 27 Aug 2004 09:03:46 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gPc-0000kM-2M for tsvwg@ietf.org; Fri, 27 Aug 2004 09:05:00 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7RD3DDE022664; Fri, 27 Aug 2004 08:03:15 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id SAA16938; Fri, 27 Aug 2004 18:25:11 -0500 (GMT) Message-ID: <412F3229.4000402@axesb2.usa.alcatel.com> Date: Fri, 27 Aug 2004 18:37:53 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk References: <412F0387.1010001@axesb2.usa.alcatel.com> <20040827042845.A11286@openss7.org> <412F1434.7090508@axesb2.usa.alcatel.com> <20040827061238.A13333@openss7.org> X-Spam-Score: 0.5 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0921362220==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 --===============0921362220== Content-Type: multipart/alternative; boundary="------------040307070207040208040907" --------------040307070207040208040907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian, Thanks for the input. Bhanu. Brian F. G. Bidulock wrote: >bhanu, > > > >>But the Section 9.1 says: >>"An endpoint MUST NOT respond to any received packet that contains an >>Abort chunk". >> >> > >Why do you think COOKIE ECHO is special? > >--brian > >On Fri, 27 Aug 2004, bhanu wrote: > > > >> Hi >> If a control chunk (for example the COOKIE ECHO chunk) is bundled >> (before)with ABORT >> what should be the response from the receiver of the bundled >> packet...??? >> (As per you it should not respond..!!!!!) >> Thanks >> Bhanu.. >> Brian F. G. Bidulock wrote: >> >>bhanu, >> >>On Fri, 27 Aug 2004, bhanu wrote: >> >> >> >>Hi >> >>Regarding the processing of an ABORT chunk bundled with other control >>chunks, >>the following sections of RFC 2960 are somewhat conflicting: >> >>The section 3.3.7 says: >>"Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) >> MAY be bundled with an ABORT but they MUST be placed before the ABORT >> in the SCTP packet, or they will be ignored by the receiver." >>It means that the chunks bundled before ABORT chunk should be processed. >> >>But the Section 9.1 says: >>"An endpoint MUST NOT respond to any received packet that contains an >>Abort chunk". >> >> >>This says that the endpoint must not _respond_ it doesn't say that the >>chunks ahead of the ABORT are not processed. >> >>--brian >> >> >> >>Again the Section 6.10 says: >> >>"An endpoint MUST process received chunks in their order in the packet". >> >>Can anybody guide us in this regard. >> >>Regards >>Bhanu. >> >> >>_______________________________________________ >>tsvwg mailing list >>[1]tsvwg@ietf.org >>[2]https://www1.ietf.org/mailman/listinfo/tsvwg >> >>References >> >> 1. mailto:tsvwg@ietf.org >> 2. https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > > --------------040307070207040208040907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian,

Thanks for the input.
Bhanu.

Brian F. G. Bidulock wrote:
bhanu,

  
But the Section 9.1 says:
"An endpoint MUST NOT respond to any received packet that contains an 
Abort chunk".
    

Why do you think COOKIE ECHO is special?

--brian

On Fri, 27 Aug 2004, bhanu wrote:

  
   Hi
   If  a  control  chunk  (for  example the COOKIE ECHO chunk) is bundled
   (before)with ABORT
   what  should  be  the  response  from  the  receiver  of  the  bundled
   packet...???
   (As per you it should not respond..!!!!!)
   Thanks
   Bhanu..
   Brian F. G. Bidulock wrote:

bhanu,

On Fri, 27 Aug 2004, bhanu wrote:

  

Hi

Regarding the processing of an ABORT chunk bundled with other control 
chunks,
the following sections of RFC 2960 are somewhat conflicting:

The section 3.3.7 says:
"Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE)
 MAY be bundled with an ABORT but they MUST be placed before the ABORT
 in the SCTP packet, or they will be ignored by the receiver."
It means that the chunks bundled before ABORT chunk should be processed.

But the Section 9.1 says:
"An endpoint MUST NOT respond to any received packet that contains an 
Abort chunk".
    

This says that the endpoint must not _respond_ it doesn't say that the
chunks ahead of the ABORT are not processed.

--brian

  

Again the Section 6.10 says:

"An endpoint MUST process received chunks in their order in the packet".

Can anybody guide us in this regard.

Regards
Bhanu.


_______________________________________________
tsvwg mailing list
[1]tsvwg@ietf.org
[2]https://www1.ietf.org/mailman/listinfo/tsvwg

References

   1. mailto:tsvwg@ietf.org
   2. https://www1.ietf.org/mailman/listinfo/tsvwg

--------------040307070207040208040907-- --===============0921362220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0921362220==-- From tsvwg-bounces@ietf.org Mon Aug 30 09:45:50 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 JAA23857; Mon, 30 Aug 2004 09:45:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mVa-0004We-Vc; Mon, 30 Aug 2004 09:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mOg-0003K0-G9; Mon, 30 Aug 2004 09:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZO2-0005NV-I0 for tsvwg@megatron.ietf.org; Fri, 27 Aug 2004 01:34:54 -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 BAA15007 for ; Fri, 27 Aug 2004 01:34:53 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZP6-0000ZH-OX for tsvwg@ietf.org; Fri, 27 Aug 2004 01:36:02 -0400 Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7R5YIDS021772 for ; Fri, 27 Aug 2004 00:34:20 -0500 (CDT) Received: from axspipc137 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4) id LAA18425; Fri, 27 Aug 2004 11:04:22 +0530 (IST) Message-ID: <0d7b01c48bf9$2ded71f0$7601ff0a@axspipc137> From: "Subhashini" To: Date: Fri, 27 Aug 2004 11:16:13 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Mon, 30 Aug 2004 09:40:30 -0400 Subject: [Tsvwg] [Sigtran] SCTP - Processing of Abort chunk, when bundled with other chunks X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492153934==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. --===============0492153934== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D76_01C48C27.4374D580" This is a multi-part message in MIME format. ------=_NextPart_000_0D76_01C48C27.4374D580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please refer below the statements from three different sections of RFC = 2960. Section 6.10 says "An endpoint MUST process received chunks in their = order in the packet". Section 9.1 says "An endpoint MUST NOT respond to any received packet = that contains an Abort chunk." Section 3.3.7 says "Control chunks (except for INIT, INIT ACK and = SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be placed = before the ABORT in the SCTP packet, or they will be ignored by the = receiver." Sections 6.10 and 3.3.7 together convey that the chunks bundled before = ABORT chunk should be processed as they are in the order. Sections 9.1 and 3.3.7 are contradicting to each other. Suppose say, if Cookie Echo chunk is bundled with before Abort chunk in = a packet, since the chunks should be processed in the order, Cookie Ack = will be sent to the peer first and then the Abort chunk will be = processed to abort the association. Is my understanding correct? = Otherwise, do we need to scan whole packet for the presence of Abort = chunk and then we need to decide to ignore the other chunks in the = packet? Please clarify. thanks, Subhashini ... ------=_NextPart_000_0D76_01C48C27.4374D580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Please refer below the statements from = three=20 different sections of RFC 2960.
 
Section 6.10 says "An endpoint MUST = process=20 received chunks in their order in the packet".
 
Section 9.1 says "An endpoint MUST NOT = respond to=20 any received packet that contains an Abort chunk."
 
Section 3.3.7 says "Control chunks = (except for=20 INIT, INIT ACK and SHUTDOWN COMPLETE) MAY be bundled with an ABORT but = they MUST=20 be placed before the ABORT in the SCTP packet, or they will be ignored = by the=20 receiver."
 
 
Sections 6.10 and 3.3.7 together convey = that the=20 chunks bundled before ABORT chunk should be processed as they are in the = order.
 
Sections 9.1 and 3.3.7 are = contradicting to each=20 other.
 
Suppose say, if Cookie Echo chunk is = bundled with=20 before Abort chunk in a packet, since the chunks should be processed in = the=20 order, Cookie Ack will be sent to the peer first and then the Abort = chunk will=20 be processed to abort the association. Is my understanding correct? = Otherwise,=20 do we need to scan whole packet for the presence of Abort chunk and then = we need=20 to decide to ignore the other chunks in the packet?
 
Please clarify.
 
thanks,
Subhashini = ...
------=_NextPart_000_0D76_01C48C27.4374D580-- --===============0492153934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0492153934==-- From tsvwg-bounces@ietf.org Tue Aug 31 05:02:49 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 FAA00187; Tue, 31 Aug 2004 05:02:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C24ZP-0006At-A4; Tue, 31 Aug 2004 05:04:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C24Ua-000687-4v; Tue, 31 Aug 2004 04:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C24T3-0005n3-Gk for tsvwg@megatron.ietf.org; Tue, 31 Aug 2004 04:58:17 -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 EAA00054 for ; Tue, 31 Aug 2004 04:58:15 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C24Uz-00065n-7V for tsvwg@ietf.org; Tue, 31 Aug 2004 05:00:18 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7V8vfDE021288 for ; Tue, 31 Aug 2004 03:57:43 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id OAA21263; Tue, 31 Aug 2004 14:19:39 -0500 (GMT) Message-ID: <41343E9D.4020401@axesb2.usa.alcatel.com> Date: Tue, 31 Aug 2004 14:32:21 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP- processing of bundled chunks X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Hai All While processing each chunk from a bundle, individual chunks are extracted using the chunk_length parameter as the size of that chunk. So the next chunk will be at the location = CHUNK_HEADER_SIZE + CHUNK_LENGTH. Consider the processing of any variable length chunk (e.g : COOKIE ECHO or DATA). If the chunk_length parameter of a chunk indicates a size which is more than the actual size of the chunk, what should be the action by the reciever of such chunk..??? what about extracting and processing of the chunks which are bundled after this, as the chunk_length indicates some wrong value it is not possible to know the end of this chunk. (The RFC-2960 does not talk about handling of such scenario). Can anybody guide us in this regard. Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Aug 31 10:00:46 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 KAA18935; Tue, 31 Aug 2004 10:00:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C29Dn-0004Bj-JJ; Tue, 31 Aug 2004 10:02:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C295J-0000ai-3U; Tue, 31 Aug 2004 09:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C290k-0007vi-Fk for tsvwg@megatron.ietf.org; Tue, 31 Aug 2004 09:49: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 JAA18452 for ; Tue, 31 Aug 2004 09:49:20 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C292i-0003y0-1B for tsvwg@ietf.org; Tue, 31 Aug 2004 09:51:25 -0400 Received: from [192.168.1.1] (p5089E03B.dip.t-dialin.net [80.137.224.59]) by ilsa.franken.de (Postfix) with ESMTP id 27794245C3; Tue, 31 Aug 2004 15:49:17 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <41343E9D.4020401@axesb2.usa.alcatel.com> References: <41343E9D.4020401@axesb2.usa.alcatel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B96DADE-FB54-11D8-AB7C-000A95C37894@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP- processing of bundled chunks Date: Tue, 31 Aug 2004 15:49:14 +0200 To: bhanu X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Hi Bhanu, see my comments in-line. Best regards Michael On 31. Aug 2004, at 11:02 Uhr, bhanu wrote: > Hai All > > While processing each chunk from a bundle, individual chunks are > extracted > using the chunk_length parameter as the size of that chunk. > So the next chunk will be at the location = CHUNK_HEADER_SIZE + > CHUNK_LENGTH. > No, the chunk size does include the chunk header, So you need to do offset += ADD_PADDING(chunk_length) where ADD_PADDING adds the padding (0 to 3 Bytes). > Consider the processing of any variable length chunk (e.g : COOKIE > ECHO or DATA). > If the chunk_length parameter of a chunk indicates a size which is > more than the actual size > of the chunk, what should be the action by the reciever of such > chunk..??? Well, that chunk is violating the spec, right? So I would send back an ABORT with error cause 'PROTOCOL VIOLATION'. > what about extracting and processing of the chunks which are bundled > after this, > as the chunk_length indicates some wrong value it is not possible to > know the end of this chunk. Since you do not know the 'real' size you have to give up, I think. That is why I'm suggesting the ABORT... > (The RFC-2960 does not talk about handling of such scenario). > > Can anybody guide us in this regard. > > Regards > Bhanu. > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Aug 31 10:22: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 KAA21199; Tue, 31 Aug 2004 10:22:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C29ZB-0004Zt-R2; Tue, 31 Aug 2004 10:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C29U2-0001Ha-Ej; Tue, 31 Aug 2004 10:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C29Ox-0008CD-Jb for tsvwg@megatron.ietf.org; Tue, 31 Aug 2004 10:14:23 -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 KAA20471 for ; Tue, 31 Aug 2004 10:14:21 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C29Qt-0004Qx-Ro for tsvwg@ietf.org; Tue, 31 Aug 2004 10:16:27 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i7VEDiDS012545; Tue, 31 Aug 2004 09:13:46 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id TAA21943; Tue, 31 Aug 2004 19:35:41 -0500 (GMT) Message-ID: <413488B0.20806@axesb2.usa.alcatel.com> Date: Tue, 31 Aug 2004 19:48:24 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP- processing of bundled chunks References: <41343E9D.4020401@axesb2.usa.alcatel.com> <8B96DADE-FB54-11D8-AB7C-000A95C37894@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hai Michael The feedback was helpfull But again, is it really possible to find out wheather the size indicated by the chunk_length parameter is correct or not..??? Is there exists an ABORT with error cause 'PROTOCOL VIOLATION' !!!!! Thanks Bhanu. Michael Tuexen wrote: > Hi Bhanu, > > see my comments in-line. > > Best regards > Michael > > On 31. Aug 2004, at 11:02 Uhr, bhanu wrote: > >> Hai All >> >> While processing each chunk from a bundle, individual chunks are >> extracted >> using the chunk_length parameter as the size of that chunk. >> So the next chunk will be at the location = CHUNK_HEADER_SIZE + >> CHUNK_LENGTH. >> > No, the chunk size does include the chunk header, So you need to do > offset += ADD_PADDING(chunk_length) > where ADD_PADDING adds the padding (0 to 3 Bytes). > >> Consider the processing of any variable length chunk (e.g : COOKIE >> ECHO or DATA). >> If the chunk_length parameter of a chunk indicates a size which is >> more than the actual size >> of the chunk, what should be the action by the reciever of such >> chunk..??? > > Well, that chunk is violating the spec, right? So I would send back an > ABORT with error cause 'PROTOCOL VIOLATION'. > >> what about extracting and processing of the chunks which are bundled >> after this, >> as the chunk_length indicates some wrong value it is not possible to >> know the end of this chunk. > > Since you do not know the 'real' size you have to give up, I think. > That is > why I'm suggesting the ABORT... > >> (The RFC-2960 does not talk about handling of such scenario). >> >> Can anybody guide us in this regard. >> >> Regards >> Bhanu. >> >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Aug 31 10:53:20 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 KAA23147; Tue, 31 Aug 2004 10:53:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2A2e-0005CA-P4; Tue, 31 Aug 2004 10:55:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C29xS-0006W1-Et; Tue, 31 Aug 2004 10:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C29rD-0004y9-0E for tsvwg@megatron.ietf.org; Tue, 31 Aug 2004 10:43: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 KAA22564 for ; Tue, 31 Aug 2004 10:43:33 -0400 (EDT) Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C29tB-0004zG-Lj for tsvwg@ietf.org; Tue, 31 Aug 2004 10:45:39 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id DEC34F244; Tue, 31 Aug 2004 09:43:01 -0500 (CDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 6093B269E; Tue, 31 Aug 2004 10:43:01 -0400 (EDT) Message-ID: <41348E74.8010000@hp.com> Date: Tue, 31 Aug 2004 10:43:00 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: bhanu Subject: Re: [Tsvwg] SCTP- processing of bundled chunks References: <41343E9D.4020401@axesb2.usa.alcatel.com> <8B96DADE-FB54-11D8-AB7C-000A95C37894@lurchi.franken.de> <413488B0.20806@axesb2.usa.alcatel.com> In-Reply-To: <413488B0.20806@axesb2.usa.alcatel.com> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: Michael Tuexen , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Bhanu bhanu wrote: > Hai Michael > > The feedback was helpfull > > But again, is it really possible to find out wheather the size indicated > by the > chunk_length parameter is correct or not..??? I think, as long as the end of the chunk is computed to be within the payload, you have to assume that it's valid. The only additional assuarances I can think of require some sort of transport or network security. > > Is there exists an ABORT with error cause 'PROTOCOL VIOLATION' !!!!! It is definied in the SCTP Implementer's Guide (draft-ietf-tsvwg-sctpimpguide-nn). -vlad > > Thanks > Bhanu. > > > Michael Tuexen wrote: > >> Hi Bhanu, >> >> see my comments in-line. >> >> Best regards >> Michael >> >> On 31. Aug 2004, at 11:02 Uhr, bhanu wrote: >> >>> Hai All >>> >>> While processing each chunk from a bundle, individual chunks are >>> extracted >>> using the chunk_length parameter as the size of that chunk. >>> So the next chunk will be at the location = CHUNK_HEADER_SIZE + >>> CHUNK_LENGTH. >>> >> No, the chunk size does include the chunk header, So you need to do >> offset += ADD_PADDING(chunk_length) >> where ADD_PADDING adds the padding (0 to 3 Bytes). >> >>> Consider the processing of any variable length chunk (e.g : COOKIE >>> ECHO or DATA). >>> If the chunk_length parameter of a chunk indicates a size which is >>> more than the actual size >>> of the chunk, what should be the action by the reciever of such >>> chunk..??? >> >> >> Well, that chunk is violating the spec, right? So I would send back an >> ABORT with error cause 'PROTOCOL VIOLATION'. >> >>> what about extracting and processing of the chunks which are bundled >>> after this, >>> as the chunk_length indicates some wrong value it is not possible to >>> know the end of this chunk. >> >> >> Since you do not know the 'real' size you have to give up, I think. >> That is >> why I'm suggesting the ABORT... >> >>> (The RFC-2960 does not talk about handling of such scenario). >>> >>> Can anybody guide us in this regard. >>> >>> Regards >>> Bhanu. >>> >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >> >> >> > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Aug 31 11:06:18 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 LAA23771; Tue, 31 Aug 2004 11:06:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AFD-0005ST-Nk; Tue, 31 Aug 2004 11:08:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2A9v-0008Rv-Hy; Tue, 31 Aug 2004 11:02:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2A69-00082b-HG for tsvwg@megatron.ietf.org; Tue, 31 Aug 2004 10:59:01 -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 KAA23392 for ; Tue, 31 Aug 2004 10:58:59 -0400 (EDT) Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2A88-0005IJ-I6 for tsvwg@ietf.org; Tue, 31 Aug 2004 11:01:05 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 6A90D56 for ; Tue, 31 Aug 2004 09:58:29 -0500 (CDT) Received: from [16.140.64.96] (galen.zk3.dec.com [16.140.64.96]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E05725710; Tue, 31 Aug 2004 09:58:28 -0500 (CDT) Message-ID: <41349214.4090405@hp.com> Date: Tue, 31 Aug 2004 10:58:28 -0400 From: Vladislav Yasevich User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP-Processing of bundled abort chunk References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On a similar note, what are the scenarios where bundling of any chunk with ABORT is usefull? The only one I can think of is an ERROR chunk. Anything else might as well not be sent. -vlad Sonali Francis wrote: > Here the next obvious question may be, what if the sender of control > chunks, bundled with ABORT needs a response back. > But, can you identify any such scenario? In my opinion, there wont be any > such situation where the sender of ABORT need any response back other than > aborting the association. > > Regards, > > Sonali -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg