From mailman-bounces@ietf.org Thu Jul 1 07:09:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14746 for ; Thu, 1 Jul 2004 07:09:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfzRG-0001d7-QL for tsvwg-archive@ietf.org; Thu, 01 Jul 2004 07:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfzQI-0001FB-00 for tsvwg-archive@ietf.org; Thu, 01 Jul 2004 07:08:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfzPk-0000r6-00 for tsvwg-archive@ietf.org; Thu, 01 Jul 2004 07:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfxh8-0002pZ-RA for tsvwg-archive@ietf.org; Thu, 01 Jul 2004 05:17:26 -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: Thu, 01 Jul 2004 05:04:07 -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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Mon Jul 12 21:13:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08491 for ; Mon, 12 Jul 2004 21:13:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkBqx-00067x-TT for tsvwg-archive@ietf.org; Mon, 12 Jul 2004 21:13:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkBpv-0005o7-00 for tsvwg-archive@ietf.org; Mon, 12 Jul 2004 21:12:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkBoy-0005G5-00; Mon, 12 Jul 2004 21:11:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkAlf-0007w0-Ti; Mon, 12 Jul 2004 20:03:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk7ep-0000Ff-F1 for tsvwg@megatron.ietf.org; Mon, 12 Jul 2004 16:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11033 for ; Mon, 12 Jul 2004 16:44:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk7eo-0000kU-7m for tsvwg@ietf.org; Mon, 12 Jul 2004 16:44:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk7aA-0007R4-00 for tsvwg@ietf.org; Mon, 12 Jul 2004 16:39:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Bk7Y5-0006eI-00; Mon, 12 Jul 2004 16:37:17 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6CKaOJ29278; Mon, 12 Jul 2004 13:36:24 -0700 (PDT) Message-ID: <40F2F69C.3080605@isi.edu> Date: Mon, 12 Jul 2004 13:37:48 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm , tsvwg References: <200406172051.i5HKp9CS000589@cougar.icir.org> In-Reply-To: <200406172051.i5HKp9CS000589@cougar.icir.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [Tsvwg] new ID on TCP antispoofing 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="===============0097895767==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0097895767== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE21C96CE1DA955B54FCFDFB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE21C96CE1DA955B54FCFDFB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, The following ID will appear shortly (available at www.isi.edu/touch/pubs/draft-touch-tcp-antispoof-00.txt in the meantime), and is an attempt to summarize the April TCP spoofing attacks on BGP and the set of possible solutions. The topic was raised in the TCPM WG this past April in response to a proposed solution based on a TCP modification. Because this draft covers the set of solutions, some involving TCP mods, and others not, but focuses on the vulnerability of TCP to spoofing more generally, IMO it would be more useful to discuss it further at the TSVWG meeting in San Diego. Joe PS - the bulk of this doc appeared previously as draft-touch-anonsec-00.txt; that draft is being updated and draft-touch-anonsec-01 now (or by next Monday ;-) focuses specifically on the need for anonymous security, and is scheduled to be presented at SAAG (security open area meeting) in San Diego. ------------------------- Network Working Group J. Touch Internet-Draft USC/ISI Expires: January 8, 2005 July 10, 2004 Defending TCP Against Spoofing Attacks draft-touch-tcp-antispoof Abstract Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. --------------enigDE21C96CE1DA955B54FCFDFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8vahE5f5cImnZrsRAgMJAKDkiCpI0pkroV1L6REfJhNUbadCtQCeKsAP hE8E0MojRnX2iK9oCeCtA4M= =nNnt -----END PGP SIGNATURE----- --------------enigDE21C96CE1DA955B54FCFDFB-- --===============0097895767== 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 --===============0097895767==-- From tsvwg-bounces@ietf.org Tue Jul 13 02:22:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14039 for ; Tue, 13 Jul 2004 02:22:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkGg6-0004Lc-FL for tsvwg-archive@ietf.org; Tue, 13 Jul 2004 02:22:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkGfB-000451-00 for tsvwg-archive@ietf.org; Tue, 13 Jul 2004 02:21:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkGeN-0003ZN-00; Tue, 13 Jul 2004 02:20:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkGXT-0004ul-HE; Tue, 13 Jul 2004 02:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkGUR-0002Z6-HR for tsvwg@megatron.ietf.org; Tue, 13 Jul 2004 02:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09539 for ; Tue, 13 Jul 2004 02:10:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkGUP-00014k-FS for tsvwg@ietf.org; Tue, 13 Jul 2004 02:10:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkGTO-0000li-00 for tsvwg@ietf.org; Tue, 13 Jul 2004 02:09:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BkGSV-0000I8-00 for tsvwg@ietf.org; Tue, 13 Jul 2004 02:08:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 12 Jul 2004 23:04:00 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6D61QCb012431; Mon, 12 Jul 2004 23:02:58 -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 XAA22364; Mon, 12 Jul 2004 23:01:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20040713005409.02684f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jul 2004 01:02:00 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Peterson, Jon" , Allison Mankin Subject: [Tsvwg] New ID on RSVP Aggregate Bandwidth Reduction announced 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hey Wanted to point to a new Internet Draft that was just announced on a proposed new RSVP extension to address an optimization that we believe is possible when dealing with RSVP Aggregates. The new ID can be found at: http://www.ietf.org/internet-drafts/draft-polk-rsvp-aggregate-reduction-00.txt Comments are requested Here is the Abstract: This document proposes an extension to the Resource Reservation Protocol (RSVP) that allows an aggregated reservation to be partially preempted. Currently, when a higher priority reservation request arrives and sufficient bandwidth is unavailable to meet that request, a lower priority aggregated reservation may be preempted in whole, whether or not the entire bandwidth is required. This document describes a method where the lower priority aggregated reservation is preempted only to the extent to which its bandwidth is required for the higher priority request. This allows the aggregator to fail only a portion of the individual sessions that is aggregated and allow the rest of the sessions to continue unaffected. 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 Wed Jul 14 00:10:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10564 for ; Wed, 14 Jul 2004 00:10:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkb6H-0002h4-Fk for tsvwg-archive@ietf.org; Wed, 14 Jul 2004 00:10:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkaRm-0003nF-00 for tsvwg-archive@ietf.org; Tue, 13 Jul 2004 23:28:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkZx4-0006Wu-02; Tue, 13 Jul 2004 22:56:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkZoh-0007pQ-U5; Tue, 13 Jul 2004 22:48:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkVHA-0003up-Mz; Tue, 13 Jul 2004 17:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkTfY-0006NJ-2M for tsvwg@megatron.ietf.org; Tue, 13 Jul 2004 16:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11610 for ; Tue, 13 Jul 2004 16:14:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkTfW-0001PV-QA for tsvwg@ietf.org; Tue, 13 Jul 2004 16:14:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkTan-00002j-00 for tsvwg@ietf.org; Tue, 13 Jul 2004 16:09:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkTWU-0006TW-00 for tsvwg@ietf.org; Tue, 13 Jul 2004 16:05:06 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkTI8-0006Il-Dj for tsvwg@ietf.org; Tue, 13 Jul 2004 15:50:16 -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 i6DJnbp18688 for ; Tue, 13 Jul 2004 15:49:37 -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 MXJC0TD8; Tue, 13 Jul 2004 15:49:36 -0400 Received: from KCHAN-2K3.nortelnetworks.com (kchan-2k3.us.nortel.com [47.16.72.116]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XZV7MAH; Tue, 13 Jul 2004 15:49:36 -0400 Message-Id: <6.0.3.0.0.20040713153830.05065fa0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 13 Jul 2004 15:49:22 -0400 To: tsvwg@ietf.org From: Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Fwd: I-D ACTION:draft-baker-diffserv-basic-classes-03.txt 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 FYI. As discussed during the TSVWG Session in the Seoul IETF (59th), March 2004; need to have more review of this draft by the members of TSVWG WG. This version of the draft incorporated the comments received via the TSVWG mailing list and from E-Mail/discussions sent to the authors. This version have also improved the content and English writing of the draft (we think :)). Please review and provide comments (especially the official reviewers). Thanks! -- Kwok Ho Chan -- >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Fri, 09 Jul 2004 11:27:58 -0400 >Subject: I-D ACTION:draft-baker-diffserv-basic-classes-03.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-SMTP-HELO: megatron.ietf.org >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org >X-SMTP-PEER-INFO: megatron.ietf.org [132.151.6.71] > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Configuration Guidelines for DiffServ Service > Classes > Author(s) : F. Baker, et al. > Filename : draft-baker-diffserv-basic-classes-03.txt > Pages : 47 > Date : 2004-7-8 > >This paper summarizes the recommended correlation between service > classes and their usage, with references to their corresponding > recommended Differentiated Service Code Points (DSCP), traffic > conditioners, Per-Hop Behaviors (PHB) and Active Queue Management > (AQM) mechanisms. There is no intrinsic requirement that particular > DSCPs, traffic conditioner PHBs and AQM be used for a certain service > class, but as a policy it is useful that they be applied consistently > across the network. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-baker-diffserv-basic-classes-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-baker-diffserv-basic-classes-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-type: message/external-body; > access-type="mail-server"; > server="mailserv@ietf.org" > >Content-Type: text/plain >Content-ID: <2004-7-9115203.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-baker-diffserv-basic-classes-03.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Jul 14 00:17:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11713 for ; Wed, 14 Jul 2004 00:17:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkbCZ-0003l8-Ig for tsvwg-archive@ietf.org; Wed, 14 Jul 2004 00:17:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkab8-00057G-00 for tsvwg-archive@ietf.org; Tue, 13 Jul 2004 23:38:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bka4B-0007fP-00; Tue, 13 Jul 2004 23:04:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkVd8-0004B0-Al; Tue, 13 Jul 2004 18:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkUPm-0002N8-K9 for tsvwg@megatron.ietf.org; Tue, 13 Jul 2004 17:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17563 for ; Tue, 13 Jul 2004 17:02:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkUPl-00065U-Aj for tsvwg@ietf.org; Tue, 13 Jul 2004 17:02:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkUKA-0004ee-00 for tsvwg@ietf.org; Tue, 13 Jul 2004 16:56:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BkUEK-00031C-00; Tue, 13 Jul 2004 16:50:24 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6DKmrJ23284; Tue, 13 Jul 2004 13:48:53 -0700 (PDT) Message-Id: <200407132048.i6DKmrJ23284@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Jul 2004 13:48:53 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [Tsvwg] RFC 3828 on The Lightweight User Datagram Protocol (UDP-Lite) 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3828 Title: The Lightweight User Datagram Protocol (UDP-Lite) Author(s): L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed. Status: Standards Track Date: July 2004 Mailbox: lln@csee.ltu.se, micke@cs.arizona.edu, steve@cs.arizona.edu, lars-erik.jonsson@ericsson.com, gorry@erg.abdn.ac.uk Pages: 12 Characters: 27193 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-udp-lite-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3828.txt This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. This document is a product of the Transport Area Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040713134549.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3828 --OtherAccess Content-Type: Message/External-body; name="rfc3828.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040713134549.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart 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 --NextPart-- From tsvwg-bounces@ietf.org Thu Jul 15 12:39:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01993 for ; Thu, 15 Jul 2004 12:39:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9GS-0004FW-Qb for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 12:39:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9FK-0003qE-00 for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 12:38:11 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9EF-0003AB-00; Thu, 15 Jul 2004 12:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl8zd-0002Ti-Um; Thu, 15 Jul 2004 12:21:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl8kW-0004ZP-BJ for tsvwg@megatron.ietf.org; Thu, 15 Jul 2004 12:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29856 for ; Thu, 15 Jul 2004 12:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl8kV-00010n-Dk for tsvwg@ietf.org; Thu, 15 Jul 2004 12:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl8jY-0000gR-00 for tsvwg@ietf.org; Thu, 15 Jul 2004 12:05:21 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Bl8ij-00002D-00; Thu, 15 Jul 2004 12:04:29 -0400 Received: from [128.9.176.213] (c2-vpn04.isi.edu [128.9.176.213]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6FG3iJ18901; Thu, 15 Jul 2004 09:03:44 -0700 (PDT) Message-ID: <40F6AAE3.30701@isi.edu> Date: Thu, 15 Jul 2004 09:03:47 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org, "'tsvwg@ietf.org'" X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [Tsvwg] New ID on TCP anti-spoofing 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="===============1892800187==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1892800187== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE405957CB4385767A1A3BE7C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE405957CB4385767A1A3BE7C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, A new ID is now available: draft-touch-tcp-antispoof-00.txt For those on TCPM, this doc is the core of the previous draft-touch-anonsec-00.txt. Here's the difference: antispoof: focuses on the spectrum of TCP antispoofing solutions, and explains why the recent attacks have become more significant (threat goes as square of bandwidth increase) anonsec-01: discusses the use of IPsec and TCP/MD5 for anonymous client access, including existing configurations and some extensions that may be useful for even simpler configuration and higher performance antispoof is intended to be of general transport-area interest, but will be presented at TCPM in San Diego to continue the thread created there by the IESG. anonsec-01 will be presented separately at the security open area meeting (SAAG) in San Diego. FYI, that draft has not yet been posted (it focuses on the anonsec-specific portions of anonsec-00). FYI - both docs are under 3667's "no derivative works, no mods" clause. If accepted for further development by an IETF WG, those clauses will be emended as required. Feedback appreciated. Joe --------------enigE405957CB4385767A1A3BE7C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9qrjE5f5cImnZrsRArcnAJ9Q5XAnYpEdCMUwzGwIqH4okCrOBACgqIDn /pwdDD9ApgHAwTDn8HN7i6Y= =JIFf -----END PGP SIGNATURE----- --------------enigE405957CB4385767A1A3BE7C-- --===============1892800187== 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 --===============1892800187==-- From tsvwg-bounces@ietf.org Thu Jul 15 13:38:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07135 for ; Thu, 15 Jul 2004 13:38:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlABk-0001ZX-0i for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 13:38:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlA9l-000108-00 for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 13:36:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BlA8c-0000cb-01; Thu, 15 Jul 2004 13:35:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BlA5i-000313-Fo; Thu, 15 Jul 2004 13:32:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9qa-0003FW-3H; Thu, 15 Jul 2004 13:16:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9fo-0008Dt-0o for tsvwg@megatron.ietf.org; Thu, 15 Jul 2004 13:05:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04401 for ; Thu, 15 Jul 2004 13:05:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9fm-0005fW-Vc for tsvwg@ietf.org; Thu, 15 Jul 2004 13:05:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9es-0005Ku-00 for tsvwg@ietf.org; Thu, 15 Jul 2004 13:04:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bl9eA-0004xg-00; Thu, 15 Jul 2004 13:03:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2004 10:04:25 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6FH3Bau009726; Thu, 15 Jul 2004 10:03:11 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AXC02293; Thu, 15 Jul 2004 10:03:00 -0700 (PDT) Message-ID: <40F6B8BE.1060900@cisco.com> Date: Thu, 15 Jul 2004 13:02:54 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch References: <40F6AAE3.30701@isi.edu> In-Reply-To: <40F6AAE3.30701@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "'tsvwg@ietf.org'" Subject: [Tsvwg] Re: [tcpm] New ID on TCP anti-spoofing 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Joe: > > FYI - both docs are under 3667's "no derivative works, no mods" > clause. If accepted for further development by an IETF WG, those > clauses will be emended as required. Any particular reason why you don't want the ietf to change your documents on the way to becoming an RFC? (or am I reading that section wrong of 3667?)?? Or are you stating in the second sentence that if someone takes it on as a wg item you will remove the "no derivative/no mod" clause from the drafts?? R -- Randall R. Stewart ITD - Transport Technologies 803-345-0369(o) or 815-342-5222(c) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jul 15 13:41:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07659 for ; Thu, 15 Jul 2004 13:41:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlAEg-0002UX-EO for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 13:41:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlADC-000201-00 for tsvwg-archive@ietf.org; Thu, 15 Jul 2004 13:40:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BlAAp-0001G1-00; Thu, 15 Jul 2004 13:37:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BlAAq-0003BK-II; Thu, 15 Jul 2004 13:37:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlA0E-0007ou-1j; Thu, 15 Jul 2004 13:26:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9oJ-00028O-BB for tsvwg@megatron.ietf.org; Thu, 15 Jul 2004 13:14:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04943 for ; Thu, 15 Jul 2004 13:14:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9oI-0000u0-6m for tsvwg@ietf.org; Thu, 15 Jul 2004 13:14:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9nT-0000ZY-00 for tsvwg@ietf.org; Thu, 15 Jul 2004 13:13:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9mV-0007jo-00; Thu, 15 Jul 2004 13:12:27 -0400 Received: from [192.168.123.144] (lsanca1-ar42-4-61-190-040.lsanca1.dsl-verizon.net [4.61.190.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6FH8nJ04711; Thu, 15 Jul 2004 10:08:49 -0700 (PDT) Message-ID: <40F6BA23.7030103@isi.edu> Date: Thu, 15 Jul 2004 10:08:51 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" References: <40F6AAE3.30701@isi.edu> <40F6B8BE.1060900@cisco.com> In-Reply-To: <40F6B8BE.1060900@cisco.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "'tsvwg@ietf.org'" Subject: [Tsvwg] Re: [tcpm] New ID on TCP anti-spoofing 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="===============1118715651==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1118715651== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2F3A3C96C33FABFD556B467" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2F3A3C96C33FABFD556B467 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Joe: > >> >> FYI - both docs are under 3667's "no derivative works, no mods" >> clause. If accepted for further development by an IETF WG, those >> clauses will be emended as required. > > Any particular reason why you don't want the ietf to change your > documents on the way to becoming an RFC? (or am I reading > that section wrong of 3667?)?? Or are you stating in the second > sentence that if someone takes it on as a wg item you will > remove the "no derivative/no mod" clause from the drafts?? That's what I'm stating in the second sentence. I.e., if the IETF doesn't take them on, I retain edit rights, e.g., if they are instead published as individual RFCs or published elsewhere. > R --------------enigD2F3A3C96C33FABFD556B467 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9rojE5f5cImnZrsRAtVKAKCW2CFJu8oB7FqEXd60pgsHd1VrJQCg7Ti8 4t+3Avdl1rzV3gYAw6tUn88= =PkS/ -----END PGP SIGNATURE----- --------------enigD2F3A3C96C33FABFD556B467-- --===============1118715651== 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 --===============1118715651==-- From tsvwg-bounces@ietf.org Sat Jul 17 18:15:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11206 for ; Sat, 17 Jul 2004 18:15:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlxSq-0007ms-61 for tsvwg-archive@ietf.org; Sat, 17 Jul 2004 18:15:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlxRq-0007XW-00 for tsvwg-archive@ietf.org; Sat, 17 Jul 2004 18:14:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlxRH-0007Go-00; Sat, 17 Jul 2004 18:13:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlxNg-0001fS-Fg; Sat, 17 Jul 2004 18:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlxN0-0001M4-6n for tsvwg@megatron.ietf.org; Sat, 17 Jul 2004 18:09:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10447 for ; Sat, 17 Jul 2004 18:09:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlxMy-0006F4-PH for tsvwg@ietf.org; Sat, 17 Jul 2004 18:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlxM2-0005yq-00 for tsvwg@ietf.org; Sat, 17 Jul 2004 18:08:27 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BlxLd-0005jk-00 for tsvwg@ietf.org; Sat, 17 Jul 2004 18:08:01 -0400 Received: from [192.168.1.218] (p5089F14A.dip.t-dialin.net [80.137.241.74]) by ilsa.franken.de (Postfix) with ESMTP id ABA73245C4 for ; Sun, 18 Jul 2004 00:05:05 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: tsvwg@ietf.org From: Michael Tuexen Date: Sun, 18 Jul 2004 00:07:42 +0200 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP chunk authentication 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear all, I've just submitted a new version of the ID describing an extension for SCTP which can be used for chunk authentication. You can also get it from: http://www.sctp.de/internet-drafts/draft-tuexen-sctp-auth-chunk-01.txt The major change is that we have included a mechanism for key agreement based on DH. Best regards Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Jul 18 08:30:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06370 for ; Sun, 18 Jul 2004 08:30:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmAnr-0000YM-7A for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 08:30:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmAmr-0000Lw-00 for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 08:29:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmAmX-00009G-00; Sun, 18 Jul 2004 08:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmAiy-0003zB-4q; Sun, 18 Jul 2004 08:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmAf5-0003b4-K5 for tsvwg@megatron.ietf.org; Sun, 18 Jul 2004 08:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05968 for ; Sun, 18 Jul 2004 08:20:57 -0400 (EDT) From: Laconsults@aol.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmAf3-0006RA-T9 for tsvwg@ietf.org; Sun, 18 Jul 2004 08:20:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmAe3-0006Dr-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 08:19:56 -0400 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx with esmtp (Exim 4.12) id 1BmAdO-0005pn-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 08:19:14 -0400 Received: from Laconsults@aol.com by imo-m24.mx.aol.com (mail_out_v37_r2.6.) id 7.1e1.258c63b0 (16335); Sun, 18 Jul 2004 08:14:39 -0400 (EDT) Message-ID: <1e1.258c63b0.2e2bc3af@aol.com> Date: Sun, 18 Jul 2004 08:14:39 EDT Subject: Re: [Tsvwg] Next Generation TCP/IP Open Source Technology Downloads Link To: sliang@dsg.stanford.edu MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 540 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="===============0599756369==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,CLICK_BELOW_CAPS, FREE_TRIAL,HTML_LINK_CLICK_CAPS,HTML_LINK_CLICK_HERE,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,LINES_OF_YELLING_2, NO_REAL_NAME,UPPERCASE_25_50 autolearn=no version=2.60 --===============0599756369== Content-Type: multipart/alternative; boundary="part1_1e1.258c63b0.2e2bc3af_boundary" --part1_1e1.258c63b0.2e2bc3af_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 15 March 2004 NEWS FLASH : Independent tests by IPv6 Research Group now confirmed TCP Expert's Technology Report below ... " ... Not a single packet dropped on tests performed, but heavy load is placed on the router" DOWNLOAD TEST REPORT CLICK HERE TO DOWNLOAD NEXT GENERATION LINUX TCP FREE TRIAL SOFTWARE OPEN SOURCE UPGRADE (& complete Technology Guide) FOR INSTANT PSTN QUALITY GUARANTEED SERVICE VoIP/ MULTIMEDIA ON YOUR CORPORATE PRIVATE NETWORKS/ WAN/ LAN, UP & RUNNING WITHIN HOURS. Free GPL-like Perpetual Patent License for usage within Finland, Norway, Sweden, Russia and China OR VISIT HTTP//IWXCHANGE.COM TO DOWNLOAD ANNOUNCEMENT : NEXT GENERATION TCP/IP TECHNOLOGY Instant Guaranteed Service TCP Technology all packets (both raw data & audio-visual) arrive well within perception tolerance time period 200ms max from source to destination on Internet + possibly not a single packet ever gets dropped needs just a few very simple lines of Linux TCP open source code modifications, & bye-bye to the "world wide wait" THE DECADES OLD's WORLD R&D HOLY GRAIL of TOTALLY CONGESTION FREE REAL TIME MULTIMEDIA INTERNET IS NOW HERE --part1_1e1.258c63b0.2e2bc3af_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 15 March 2004 NEWS FLASH : Indep= endent tests by IPv6 Research Group now confirmed TCP Expert's Technology Re= port below ... " ... Not a single packet dropped on tests performed, but hea= vy load is placed on the router"

DOWNL= OAD TEST REPORT CLICK HERE TO DOWNLOAD NEXT GENERATION LINUX TCP FREE TRIAL SOFT= WARE OPEN SOURCE UPGRADE (& complete Technology Guide) FOR INSTANT PSTN=20= QUALITY GUARANTEED SERVICE VoIP/ MULTIMEDIA ON YOUR CORPORATE PRIVATE NETWOR= KS/ WAN/ LAN, UP & RUNNING WITHIN HOURS. Free GPL-like Perpetual Patent=20= License for usage within Finland, Norway, Sweden, Russia and China

OR VISIT HTTP//IWXCHANGE.COM TO DOWNLOAD

ANNOUNCEMENT : NEXT GENERATION TCP/IP TECHNOLOGY Instant Guaranteed Service=20= TCP Technology

all packets (both raw data & audio-visual) arrive well within percep= tion tolerance time period 200ms max from source to destination on Internet=20= + possibly not a single packet ever gets dropped  

needs just a few very simple lines of Linux TCP open source code modificatio= ns, & bye-bye to the "world wide wait"

THE DECADES OLD's WORLD R&D HOLY GRAIL of TOTALLY CONGESTION FREE REA= L TIME MULTIMEDIA INTERNET IS NOW HERE





 --part1_1e1.258c63b0.2e2bc3af_boundary-- --===============0599756369== 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 --===============0599756369==-- From tsvwg-bounces@ietf.org Sun Jul 18 13:42:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22628 for ; Sun, 18 Jul 2004 13:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmFfw-0004sD-6O for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 13:42:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmFf9-0004g0-00 for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 13:41:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmFeU-0004TN-00; Sun, 18 Jul 2004 13:40:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmFZt-0002Sn-Cj; Sun, 18 Jul 2004 13:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmFZ8-0002Mw-4N for tsvwg@megatron.ietf.org; Sun, 18 Jul 2004 13:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22179 for ; Sun, 18 Jul 2004 13:35:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmFZ7-0003Fp-4R for tsvwg@ietf.org; Sun, 18 Jul 2004 13:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmFYD-00034W-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 13:34:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BmFXM-0002t1-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 13:33:20 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmFXM-00078Y-Gd; Sun, 18 Jul 2004 17:33:20 +0000 To: Laconsults@aol.com Subject: Re: [Tsvwg] Next Generation TCP/IP Open Source Technology Downloads Link In-reply-to: Your message of Sun, 18 Jul 2004 08:14:39 -0400. <1e1.258c63b0.2e2bc3af@aol.com> Date: Sun, 18 Jul 2004 10:33:19 -0700 From: Allison Mankin Message-Id: Cc: tsvwg@ietf.org, jon.peterson@neustar.biz 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,CLICK_BELOW_CAPS, FREE_TRIAL,HTML_LINK_CLICK_CAPS,HTML_LINK_CLICK_HERE,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,UPPERCASE_25_50 autolearn=no version=2.60 We've given you notice before that advertisement of trial software is inappropriate use of this mailing list. Do not send a message like this again. Allison Mankin Co-Chair TSVWG Working Group > > Date: Sun, 18 Jul 2004 08:14:39 EDT > To: sliang@dsg.stanford.edu > cc: tsvwg@ietf.org > From: Laconsults@aol.com > Subject: Re: [Tsvwg] Next Generation TCP/IP Open Source Technology Downloads Li > ***nk > > Return-Path: tsvwg-bounces@ietf.org > Delivery-Date: Sun Jul 18 12:29:29 2004 > Return-path: > MIME-Version: 1.0 > X-Mailer: 7.0 for Windows sub 540 > 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-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com > X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_44,CLICK_BELOW_CAPS, > FREE_TRIAL,HTML_LINK_CLICK_CAPS,HTML_LINK_CLICK_HERE,HTML_MESSAGE, > NO_REAL_NAME,UPPERCASE_25_50 autolearn=no version=2.63 > X-Spam-Level: > > > --===============0599756369== > Content-Type: multipart/alternative; > boundary="part1_1e1.258c63b0.2e2bc3af_boundary" > > > --part1_1e1.258c63b0.2e2bc3af_boundary > Content-Type: text/plain; charset="US-ASCII" > Content-Transfer-Encoding: 7bit > > 15 March 2004 NEWS FLASH : Independent tests by IPv6 Research Group now > confirmed TCP Expert's Technology Report below ... " ... Not a single packet > dropped on tests performed, but heavy load is placed on the router" > > DOWNLOAD TEST REPORT CLICK HERE TO DOWNLOAD NEXT GENERATION LINUX TCP FREE > TRIAL SOFTWARE OPEN SOURCE UPGRADE (& complete Technology Guide) FOR INSTANT > PSTN QUALITY GUARANTEED SERVICE VoIP/ MULTIMEDIA ON YOUR CORPORATE PRIVATE > NETWORKS/ WAN/ LAN, UP & RUNNING WITHIN HOURS. Free GPL-like Perpetual Patent > License for usage within Finland, Norway, Sweden, Russia and China > > OR VISIT HTTP//IWXCHANGE.COM TO DOWNLOAD > > ANNOUNCEMENT : NEXT GENERATION TCP/IP TECHNOLOGY Instant Guaranteed Service > TCP Technology > > all packets (both raw data & audio-visual) arrive well within perception > tolerance time period 200ms max from source to destination on Internet + possib > ly > not a single packet ever gets dropped > > needs just a few very simple lines of Linux TCP open source code > modifications, & bye-bye to the "world wide wait" > > THE DECADES OLD's WORLD R&D HOLY GRAIL of TOTALLY CONGESTION FREE REAL TIME > MULTIMEDIA INTERNET IS NOW HERE > > > > > > > --part1_1e1.258c63b0.2e2bc3af_boundary > Content-Type: text/html; charset="US-ASCII" > Content-Transfer-Encoding: quoted-printable > > =3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">15 March 2004 NEWS FLASH : Indep= > endent tests by IPv6 Research Group now confirmed TCP Expert's Technology Re= > port below ... " ... Not a single packet dropped on tests performed, but hea= > vy load is placed on the router"
>
> DOWNL= > OAD TEST REPORT nuxTCP.zip">CLICK HERE TO DOWNLOAD NEXT GENERATION LINUX TCP FREE TRIAL SOFT= > WARE OPEN SOURCE UPGRADE (& complete Technology Guide) FOR INSTANT PSTN=20= > QUALITY GUARANTEED SERVICE VoIP/ MULTIMEDIA ON YOUR CORPORATE PRIVATE NETWOR= > KS/ WAN/ LAN, UP & RUNNING WITHIN HOURS. Free GPL-like Perpetual Patent=20= > License for usage within Finland, Norway, Sweden, Russia and China
>
> OR VISIT HTTP//IWXCHANGE.COM TO DOWNLOAD
>
> ANNOUNCEMENT : NEXT GENERATION TCP/IP TECHNOLOGY Instant Guaranteed Service=20= > TCP Technology
>
> all packets (both raw data & audio-visual) arrive well within percep= > tion tolerance time period 200ms max from source to destination on Internet=20= > + possibly not a single packet ever gets dropped  
>
> needs just a few very simple lines of Linux TCP open source code modificatio= > ns, & bye-bye to the "world wide wait"
>
> THE DECADES OLD's WORLD R&D HOLY GRAIL of TOTALLY CONGESTION FREE REA= > L TIME MULTIMEDIA INTERNET IS NOW HERE
>
>
>
>
>
> > --part1_1e1.258c63b0.2e2bc3af_boundary-- > > > --===============0599756369== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > --===============0599756369==-- > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Jul 18 17:18:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03162 for ; Sun, 18 Jul 2004 17:18:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmJ3H-0000GA-11 for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 17:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmJ2Q-000033-00 for tsvwg-archive@ietf.org; Sun, 18 Jul 2004 17:17:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BmJ1u-0007dz-00; Sun, 18 Jul 2004 17:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmIxO-0000Rd-0r; Sun, 18 Jul 2004 17:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmIuS-00080J-KM for tsvwg@megatron.ietf.org; Sun, 18 Jul 2004 17:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02685 for ; Sun, 18 Jul 2004 17:09:21 -0400 (EDT) From: Laconsults@aol.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmIuR-0006A3-8M for tsvwg@ietf.org; Sun, 18 Jul 2004 17:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmItX-0005y6-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 17:08:28 -0400 Received: from imo-m17.mx.aol.com ([64.12.138.207]) by ietf-mx with esmtp (Exim 4.12) id 1BmIsu-0005kU-00 for tsvwg@ietf.org; Sun, 18 Jul 2004 17:07:48 -0400 Received: from Laconsults@aol.com by imo-m17.mx.aol.com (mail_out_v37_r2.6.) id p.15.2df5c90c (4552); Sun, 18 Jul 2004 17:07:11 -0400 (EDT) Message-ID: <15.2df5c90c.2e2c407f@aol.com> Date: Sun, 18 Jul 2004 17:07:11 EDT To: mankin@psg.com MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 540 Cc: tsvwg@ietf.org Subject: [Tsvwg] Next Generation TCP/IP Open Source Technology Downloads Link 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="===============1424983911==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,NO_REAL_NAME autolearn=no version=2.60 --===============1424983911== Content-Type: multipart/alternative; boundary="part1_15.2df5c90c.2e2c407f_boundary" --part1_15.2df5c90c.2e2c407f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We've given you notice before that advertisement of trial software is inappropriate use of this mailing list. Do not send a message like this again my mistake & sincere apology for inadvertent inappropriate breach of posting ethics this time. It was simply copied & paste from existing website text in a hurry. please ignore the the trial software component included in the technical guide pack, in any event the software should be completely freely available for all research purposes without registration requirements. This won't happen again --part1_15.2df5c90c.2e2c407f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable We've given you notice before that=20= advertisement of trial software is inappropriate use of this mailing list.
Do not send a message like this again


my mistake & sincere apology for inadvertent inappropriate breach of pos= ting ethics this time.

It was simply copied & paste from existing website text in a hurry.

please ignore the the trial software component included in the technical gui= de pack, in any event the software should be completely freely available for= all research purposes without registration requirements.

This won't happen again




 --part1_15.2df5c90c.2e2c407f_boundary-- --===============1424983911== 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 --===============1424983911==-- From tsvwg-bounces@ietf.org Mon Jul 19 12:32:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02945 for ; Mon, 19 Jul 2004 12:32:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bmb4I-00064B-9S for tsvwg-archive@ietf.org; Mon, 19 Jul 2004 12:32:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bmb2v-0005g7-00 for tsvwg-archive@ietf.org; Mon, 19 Jul 2004 12:31:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bmb0U-000551-00; Mon, 19 Jul 2004 12:28:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmafF-0007fM-B3; Mon, 19 Jul 2004 12:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmaVX-00062e-Tb for tsvwg@megatron.ietf.org; Mon, 19 Jul 2004 11:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29677 for ; Mon, 19 Jul 2004 11:56:48 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmaVX-0003b3-0g for tsvwg@ietf.org; Mon, 19 Jul 2004 11:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmaU4-0003GJ-00 for tsvwg@ietf.org; Mon, 19 Jul 2004 11:55:21 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BmaSI-0002xy-00; Mon, 19 Jul 2004 11:53:30 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6JFrTx05210; Mon, 19 Jul 2004 18:53:29 +0300 (EET DST) X-Scanned: Mon, 19 Jul 2004 18:53:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6JFrKU7005497; Mon, 19 Jul 2004 18:53:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ESP8Me; Mon, 19 Jul 2004 18:52:22 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6JFqGn18440; Mon, 19 Jul 2004 18:52:17 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Jul 2004 10:51:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2004 10:51:38 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E8133@daebe004.americas.nokia.com> Thread-Topic: Updated draft draft-swami-tcp-lmdr-03.txt Thread-Index: AcRtqEb1ioor27jZQnWyuKAV2rrBSA== To: , X-OriginalArrivalTime: 19 Jul 2004 15:51:39.0940 (UTC) FILETIME=[47C76640:01C46DA8] Content-Transfer-Encoding: quoted-printable Cc: khiem.le@nokia.com Subject: [Tsvwg] Updated draft draft-swami-tcp-lmdr-03.txt 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hello Folks, We have submitted a new draft that addresses some of the TCP performance = issues related to subnet change. The draft also addresses some of the = congestion related issues. We are proposing a 3-byte TCP option that = mobility-aware end-points (i.e., mobile devices and servers that = communicate with mobile devices) need to implement. This draft has been in IETF for a long time, and we will greatly = appreciate any feedback from the mailing list.=20 Here is the link: = http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-03.txt Looking forwards toward your comments. Thanks Yogesh ------------------------------------------------------------------- Abstract TCP congestion control is based on the assumption that the end-to- end path of a connection changes very infrequently (most likely due to router failure) after connection establishment. This assumption allows a TCP sender to compute (predict) a new congestion window (cwnd) based on the ACKs from previous cwnd. With host mobility, however, the assumption of "constant path" does not hold, and the present congestion control and avoidance mechanisms can lead to suboptimal system performance. In this document we describes a TCP option that allows a receiver to inform the sender about subnet change; based on which, the sender can react to optimize performance. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Jul 19 19:33: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 TAA05914; Mon, 19 Jul 2004 19:33:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmhdo-0004Ru-Gr; Mon, 19 Jul 2004 19:33:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmg7y-0002vG-TZ; Mon, 19 Jul 2004 17:56:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmeML-0004M5-NO; Mon, 19 Jul 2004 16:03:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19804; Mon, 19 Jul 2004 16:03:35 -0400 (EDT) Message-Id: <200407192003.QAA19804@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 19 Jul 2004 16:03:35 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-tcp-mib-extension-05.txt 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.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : TCP Extended Statistics MIB Author(s) : M. Mathis, et al. Filename : draft-ietf-tsvwg-tcp-mib-extension-05.txt Pages : 52 Date : 2004-7-19 This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-tcp-mib-extension-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-tcp-mib-extension-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152856.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From tsvwg-bounces@ietf.org Tue Jul 20 13:34:24 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 NAA07771; Tue, 20 Jul 2004 13:34:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmyVh-0003hq-6f; Tue, 20 Jul 2004 13:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmyIs-0002zb-Cb; Tue, 20 Jul 2004 13:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmy8u-0000M2-H2 for tsvwg@megatron.ietf.org; Tue, 20 Jul 2004 13:11:04 -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 NAA06206 for ; Tue, 20 Jul 2004 13:11:01 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmy94-0003OC-C8 for tsvwg@ietf.org; Tue, 20 Jul 2004 13:11:15 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i6KHB0hF021976 for ; Tue, 20 Jul 2004 10:11:00 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i6KH3XRh018160; Tue, 20 Jul 2004 12:03:34 -0500 Message-ID: <40FD526B.1050801@motorola.com> Date: Tue, 20 Jul 2004 12:12:11 -0500 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: TSV WG list References: <40FD50DF.5070405@motorola.com> In-Reply-To: <40FD50DF.5070405@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt 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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit All, I'd like to get your feedback on this I-D. Our intention is to put together some guidelines and information for people 1) who want to run SCTP across NATs, and 2) who want to make future NAT/middleboxes more SCTP friendly. regards, -Qiaobing > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SCTP NAT Transverse Considerations > Author(s) : Q. Xie, et al. > Filename : draft-xie-tsvwg-sctp-nat-00.txt > Pages : 8 > Date : 2004-7-14 > > This document provides guidelines and solutions for dealing with SCTP > association transversing NAT and similar middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-tsvwg-sctp-nat-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Jul 20 14:34:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13908; Tue, 20 Jul 2004 14:34:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmzSF-0004rE-OD; Tue, 20 Jul 2004 14:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmzMQ-0004r9-CD; Tue, 20 Jul 2004 14:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmz6m-0000Ib-5B for tsvwg@megatron.ietf.org; Tue, 20 Jul 2004 14:12: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 OAA11616 for ; Tue, 20 Jul 2004 14:12:54 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmz6t-0004Nq-GH for tsvwg@ietf.org; Tue, 20 Jul 2004 14:13:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2004 11:13:55 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6KICHNv015870; Tue, 20 Jul 2004 11:12:17 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id AXF60144; Tue, 20 Jul 2004 11:12:14 -0700 (PDT) Date: Tue, 20 Jul 2004 14:11:58 -0400 Subject: Re: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) To: Qiaobing Xie From: Melinda Shore In-Reply-To: <40FD526B.1050801@motorola.com> Message-Id: <4A73B9A7-DA78-11D8-912A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: TSV WG list 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit There's a middle case which may bear mention, and that's that in the case of a multihomed association a NAT may choose to create one NAT table mapping per endpoint address. Yes, that's wasteful, but it's implementable without introducing new data structures (list of addresses) within the NAT. I'm not sure I agree with the conclusion in section 3.2 that there needs to be an inter-NAT protocol. I would look to see if there's some way that the verification tag could be used to identify packets that belong to a particular association, or perhaps it would be more effective to add an association identifier TLV of some sort. An inter-NAT protocol is going to be a big project and is going to introduce a very considerable ugliness into the scenario, which is the question of how the NATs know about each other. Worse, it would mean that every NAT you traversed would need to run that protocol. It would be better, I think, to use a mechanism that didn't require support from the NAT itself. Melinda _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Jul 21 14:56: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 OAA12560; Wed, 21 Jul 2004 14:56:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMGv-0007As-Qx; Wed, 21 Jul 2004 14:56:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMEf-0006ex-FX; Wed, 21 Jul 2004 14:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnME6-0006QM-Ew for tsvwg@megatron.ietf.org; Wed, 21 Jul 2004 14:54: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 OAA12455 for ; Wed, 21 Jul 2004 14:54:00 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMEU-00079L-Ei for tsvwg@ietf.org; Wed, 21 Jul 2004 14:54:27 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i6LIruXQ015669; Wed, 21 Jul 2004 11:53:56 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i6LIkSRh013386; Wed, 21 Jul 2004 13:46:29 -0500 Message-ID: <40FEBC0B.4060908@motorola.com> Date: Wed, 21 Jul 2004 13:55:07 -0500 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: Melinda Shore Subject: Re: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt References: <4A73B9A7-DA78-11D8-912A-000A95E35274@cisco.com> In-Reply-To: <4A73B9A7-DA78-11D8-912A-000A95E35274@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: TSV WG list 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Melinda, Thanks for the comments. Melinda Shore wrote: > There's a middle case which may bear mention, and that's that in > the case of a multihomed association a NAT may choose to create > one NAT table mapping per endpoint address. Yes, that's wasteful, > but it's implementable without introducing new data structures (list > of addresses) within the NAT. Good point. > > I'm not sure I agree with the conclusion in section 3.2 that there > needs to be an inter-NAT protocol. I would look to see if there's > some way that the verification tag could be used to identify > packets that belong to a particular association, or perhaps it would > be more effective to add an association identifier TLV of some sort. We mentioned inter-NAT prot simply because we felt there need to be some sort of coordination/communication among the NATs so that they would uniquely identify the packets each of them sees actually belong to the same SCTP association. Whether it v-tag or a new assoc-id, you still need to sync that up among the NATs, right? ... unless it's some kind of globally defined numbering scheme? But that seems to be more difficult to establish. > An inter-NAT protocol is going to be a big project and is going to > introduce a very considerable ugliness into the scenario, which is > the question of how the NATs know about each other. Worse, it would > mean that every NAT you traversed would need to run that protocol. We were hoping some existing/work-in-progress inter-middlebox mechanism (e.g., midcom, nsis, ...) could give us a hand :-) I agree to create a new inter-NAT protocol is a big project. > It would be better, I think, to use a mechanism that didn't require > support from the NAT itself. That would be ideal. regards, -Qiaobing > > Melinda > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Jul 21 17:33: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 RAA06119; Wed, 21 Jul 2004 17:33:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnOiR-0004uH-Hv; Wed, 21 Jul 2004 17:33:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMyh-00072l-KK; Wed, 21 Jul 2004 15:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMt3-0004lg-Og for tsvwg@megatron.ietf.org; Wed, 21 Jul 2004 15:36: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 PAA16729 for ; Wed, 21 Jul 2004 15:36:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnMtS-0007hb-4T for tsvwg@ietf.org; Wed, 21 Jul 2004 15:36:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2004 12:38:03 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6LJZjIV005795; Wed, 21 Jul 2004 12:35:45 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id AXG83561; Wed, 21 Jul 2004 12:35:44 -0700 (PDT) Date: Wed, 21 Jul 2004 15:35:28 -0400 Subject: Re: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) To: Qiaobing Xie From: Melinda Shore In-Reply-To: <40FEBC0B.4060908@motorola.com> Message-Id: <1EEE64FA-DB4D-11D8-912A-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: TSV WG list 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Wednesday, July 21, 2004, at 02:55 PM, Qiaobing Xie wrote: > We mentioned inter-NAT prot simply because we felt there need to be > some sort of coordination/communication among the NATs so that they > would uniquely identify the packets each of them sees actually belong > to the same SCTP association. Whether it v-tag or a new assoc-id, you > still need to sync that up among the NATs, right? ... unless it's some > kind of globally defined numbering scheme? But that seems to be more > difficult to establish. There are several ways of actively dealing with NATs. My preferred way is to take it outside, set it on a hard surface, and pound it repeatedly with a heavy object, but that's not always an option. Basically it comes down to using a relay, which obviously is not an appropriate general solution, or being able to talk directly to the NAT and request a NAT table mapping, or to try to make your protocol more NAT-friendly. Unfortunately using an explicit list of addresses to define the association is not very NAT-friendly. If you're going to talk to the NAT directly, you'll need a protocol to do that. Neither midcom nor nsis is complete, although midcom is close. Talking to the NAT directly means finding the appropriate one. That's extremely difficult to do with midcom in a multihomed scenario. I'll spare you my opinion of nsis. UPnP is basically midcom in consumer-oriented devices and it's currently available, but it suffers from the same shortcomings as midcom in topologically complex networks. I think that in the circumstances you're describing your best bet is to not touch the NAT at all (beyond adding basic SCTP support in the first place) and instead use low-probability identifiers combined with authentication (on the odd chance that you have a collision). The obvious problem is that this is not how SCTP currently identifies members of an association, but this could be added as an extra check rather than as a replacement for the current logic. It also obviates the extra messaging and "post-dial delay" that would come with using a protocol that communicates directly with the NAT, as well as the requirement that the NAT communication protocol be supported in every device involved. So that's my bias for this kind of problem. Unfortunately there's rarely a low-cost solution for NAT traversal problems. Melinda _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jul 22 09:20: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 JAA18282; Thu, 22 Jul 2004 09:20:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BndVX-0001CP-Or; Thu, 22 Jul 2004 09:21:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BndRV-0001MB-QJ; Thu, 22 Jul 2004 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BndFP-0004gW-Gi for tsvwg@megatron.ietf.org; Thu, 22 Jul 2004 09:04: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 JAA17141 for ; Thu, 22 Jul 2004 09:04:29 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BndFM-0000tR-J0 for tsvwg@ietf.org; Thu, 22 Jul 2004 09:05:06 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i6MD3pqO011242 for ; Thu, 22 Jul 2004 15:03:51 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i6MD3oG24785 for ; Thu, 22 Jul 2004 15:03:50 +0200 (MEST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i6MD3oU9000971 for ; Thu, 22 Jul 2004 15:03:50 +0200 Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jul 2004 15:03:49 +0200 Message-ID: From: Schruefer Wolfgang To: tsvwg@ietf.org Date: Thu, 22 Jul 2004 15:03:48 +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: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Tsvwg] SCTP: alternative ADDIP to enable NAT for mulithoming 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: cab78e1e39c4b328567edb48482b6a69 Dear all, I want to suggest an alternative ADDIP procedure to enable multi-homed SCTP associations through simple NAT boxes. Its goal is to avoid the usage of address parameters within SCTP chunks. It is just an idea, but up to now I see no restriction why it should not work ... Example configuration: Consider endpoint A (Client) has two local transport Adresses AL1 and AL2. Consider endpoint B (Server) has one or more global transport Adresses B. One or two simple NAT boxes translate addresses AL1 and AL2 to global Adresses AG1 and AG2 (just IP-Address / Port). Procedure: 1. Step: A establishes a first single-homed Association from AL1 to B. 2. Step: A establishes a second single-homed Association from AL2 to B. 3. Step: A requests B to merge the transport address of the second assoc as new path for the first association. In parallel the second association must be aborted. It could this be realized this way: 1) Definition of a new INIT/INIT-ACK parameter e.g. 'MERGE ONLY'. Purpose: To mark the second association as temporarily used for ADDIP (this association should not be used for data transport). 2) Definition of a new ASCONF (ADDIP) parameter e.g. 'MERGE SCTP ENDPOINT'. Purpose: To be sent via the first association to trigger the merger (for security this parameter should contain at least the Verification Tags of the second association, but not its transport address). 3) Removal of the Address Parameters in the ASCONF Paramters 'Delete IP Address' and 'Set Primary IP Address'. Remark: The source address of the packet including this chunk should be used instead to identify the path. 4) Removal of the SCTP restriction: all path addresses must use the same port number. Your comments are welcome! Viele Gruesse Wolfgang _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jul 22 11:37: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 LAA29865; Thu, 22 Jul 2004 11:37:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnfe4-0003k5-8Q; Thu, 22 Jul 2004 11:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnfUh-0005S9-Lg; Thu, 22 Jul 2004 11:28:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnfQl-0004Fk-HE for tsvwg@megatron.ietf.org; Thu, 22 Jul 2004 11:24: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 LAA28922 for ; Thu, 22 Jul 2004 11:24:21 -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 1BnfRL-0003WS-EM for tsvwg@ietf.org; Thu, 22 Jul 2004 11:24:59 -0400 Received: from [192.168.1.22] (p5089F043.dip.t-dialin.net [80.137.240.67]) by ilsa.franken.de (Postfix) with ESMTP id 6E0EC2463B; Thu, 22 Jul 2004 17:21:15 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3056E7E0-DBF3-11D8-943B-000D932C78D8@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP: alternative ADDIP to enable NAT for mulithoming Date: Thu, 22 Jul 2004 17:24:14 +0200 To: Schruefer Wolfgang X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Hi Wolfgang, I think it is very difficult to change the definition of an SCTP endpoint (at a given time) from a pair of a non-empty set of IP-address and a port number to a non-empty set of pair of IP-addresses and port numbers. However, if you only consider NAT boxes which translate IP-Addresses and and not port numbers than you have only to avoid transporting IP-addresses inside SCTP. You can do this by using an association identifier which you put into the INIT and INIT-ACK as a new parameter. This can be a hash to the TCB or something like this. Then you add a new chunk which acts like an ADD-IP but contains the association identifier instead of the old address. The receiver could find the association based on the association identifier and could add the source address as an additional path. Of course you would need to use the SCTP-AUTH extension to sign this new chunk, as it will be required for ADDIP. This would be a possible way do deal with NAT engines which do not look at port numbers and therefore should work with SCTP. This solution does not work with NAT engines which look at port numbers. But these boxes would need to support SCTP ... Best regards Michael On Jul 22, 2004, at 3:03 PM, Schruefer Wolfgang wrote: > Dear all, > > I want to suggest an alternative ADDIP procedure to enable multi-homed > SCTP associations through simple NAT boxes. Its goal is to avoid the > usage of address parameters within SCTP chunks. It is just an idea, > but up to now I see no restriction why it should not work ... > > > Example configuration: > Consider endpoint A (Client) has two local transport Adresses AL1 and > AL2. > Consider endpoint B (Server) has one or more global transport Adresses > B. > One or two simple NAT boxes translate addresses AL1 and AL2 to global > Adresses AG1 and AG2 (just IP-Address / Port). > > > Procedure: > > 1. Step: A establishes a first single-homed Association from AL1 to B. > > 2. Step: A establishes a second single-homed Association from AL2 to B. > > 3. Step: A requests B to merge the transport address of the second > assoc as new path for the first association. In parallel the second > association must be aborted. > > > > It could this be realized this way: > > 1) Definition of a new INIT/INIT-ACK parameter e.g. 'MERGE ONLY'. > Purpose: To mark the second association as temporarily used for ADDIP > (this association should not be used for data transport). > > 2) Definition of a new ASCONF (ADDIP) parameter e.g. 'MERGE SCTP > ENDPOINT'. > Purpose: To be sent via the first association to trigger the merger > (for security this parameter should contain at least the Verification > Tags of the second association, but not its transport address). > > 3) Removal of the Address Parameters in the ASCONF Paramters 'Delete > IP Address' and 'Set Primary IP Address'. > Remark: The source address of the packet including this chunk should > be used instead to identify the path. > > 4) Removal of the SCTP restriction: all path addresses must use the > same port number. > > > > Your comments are welcome! > > Viele Gruesse > Wolfgang > > _______________________________________________ > 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 Jul 22 12:44: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 MAA04775; Thu, 22 Jul 2004 12:44:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnggu-0004rr-JQ; Thu, 22 Jul 2004 12:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BngaT-0004vs-Ka; Thu, 22 Jul 2004 12:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BngRC-0000L7-Kd for tsvwg@megatron.ietf.org; Thu, 22 Jul 2004 12:28: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 MAA03602 for ; Thu, 22 Jul 2004 12:28:51 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BngRh-0004bi-Pq for tsvwg@ietf.org; Thu, 22 Jul 2004 12:29:31 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i6MGSl1j023339; Thu, 22 Jul 2004 18:28:47 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i6MGSlG14465; Thu, 22 Jul 2004 18:28:47 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i6MGSkU9019508; Thu, 22 Jul 2004 18:28:46 +0200 Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <374A0488>; Thu, 22 Jul 2004 18:28:46 +0200 Message-ID: From: Schruefer Wolfgang To: "'Michael Tuexen'" Subject: RE: [Tsvwg] SCTP: alternative ADDIP to enable NAT for mulithoming Date: Thu, 22 Jul 2004 18:28:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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: 36b1f8810cb91289d885dc8ab4fc8172 Hi Michael, thanks for your comments, I can imagine your idea with association identifiers could improve the procedure. But I do not unterstand your problems with the port numbers??? Maybe we should distinguish between the local port number and the remote port number: For this idea it is not necessary to change the local port number handling! The only change is that we have a different remote port number for every path. I think this should not cause difficulties, it is just an additional entry in the local path variables? Please give an example if you still see serious problems. Thanks Wolfgang > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Thursday, July 22, 2004 5:24 PM > To: Schruefer Wolfgang > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] SCTP: alternative ADDIP to enable NAT for > mulithoming > > > Hi Wolfgang, > > I think it is very difficult to change the definition of an > SCTP endpoint (at a given time) from a pair of a non-empty set > of IP-address and a port number to a non-empty set of > pair of IP-addresses and port numbers. > > However, if you only consider NAT boxes which translate IP-Addresses > and and not port numbers than you have only to avoid transporting > IP-addresses inside SCTP. > > You can do this by using an association identifier which you > put into the INIT and INIT-ACK as a new parameter. This can be > a hash to the TCB or something like this. > > Then you add a new chunk which acts like an ADD-IP but contains > the association identifier instead of the old address. The receiver > could find the association based on the association identifier and > could add the source address as an additional path. > > Of course you would need to use the SCTP-AUTH extension to sign this > new chunk, as it will be required for ADDIP. > > This would be a possible way do deal with NAT engines which do > not look at port numbers and therefore should work with SCTP. > > This solution does not work with NAT engines which look at > port numbers. But these boxes would need to support SCTP ... > > Best regards > Michael > > On Jul 22, 2004, at 3:03 PM, Schruefer Wolfgang wrote: > > > Dear all, > > > > I want to suggest an alternative ADDIP procedure to enable > multi-homed > > SCTP associations through simple NAT boxes. Its goal is to > avoid the > > usage of address parameters within SCTP chunks. It is just an idea, > > but up to now I see no restriction why it should not work ... > > > > > > Example configuration: > > Consider endpoint A (Client) has two local transport > Adresses AL1 and > > AL2. > > Consider endpoint B (Server) has one or more global > transport Adresses > > B. > > One or two simple NAT boxes translate addresses AL1 and AL2 > to global > > Adresses AG1 and AG2 (just IP-Address / Port). > > > > > > Procedure: > > > > 1. Step: A establishes a first single-homed Association > from AL1 to B. > > > > 2. Step: A establishes a second single-homed Association > from AL2 to B. > > > > 3. Step: A requests B to merge the transport address of the second > > assoc as new path for the first association. In parallel the second > > association must be aborted. > > > > > > > > It could this be realized this way: > > > > 1) Definition of a new INIT/INIT-ACK parameter e.g. 'MERGE ONLY'. > > Purpose: To mark the second association as temporarily used > for ADDIP > > (this association should not be used for data transport). > > > > 2) Definition of a new ASCONF (ADDIP) parameter e.g. 'MERGE SCTP > > ENDPOINT'. > > Purpose: To be sent via the first association to trigger the merger > > (for security this parameter should contain at least the > Verification > > Tags of the second association, but not its transport address). > > > > 3) Removal of the Address Parameters in the ASCONF > Paramters 'Delete > > IP Address' and 'Set Primary IP Address'. > > Remark: The source address of the packet including this > chunk should > > be used instead to identify the path. > > > > 4) Removal of the SCTP restriction: all path addresses must use the > > same port number. > > > > > > > > Your comments are welcome! > > > > Viele Gruesse > > Wolfgang > > > > _______________________________________________ > > 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 Jul 22 13:23: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 NAA07603; Thu, 22 Jul 2004 13:23:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnhIt-0005Vd-8Y; Thu, 22 Jul 2004 13:24:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnh4o-0001Cp-G4; Thu, 22 Jul 2004 13:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnh1M-0007j3-8g for tsvwg@megatron.ietf.org; Thu, 22 Jul 2004 13:06:16 -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 NAA06393 for ; Thu, 22 Jul 2004 13:06:13 -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 1Bnh1x-0005EK-2j for tsvwg@ietf.org; Thu, 22 Jul 2004 13:06:53 -0400 Received: from [192.168.1.22] (p5089F043.dip.t-dialin.net [80.137.240.67]) by ilsa.franken.de (Postfix) with ESMTP id 3201D2461F; Thu, 22 Jul 2004 19:03:08 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CAB41C0-DC01-11D8-A369-000D932C78D8@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP: alternative ADDIP to enable NAT for mulithoming Date: Thu, 22 Jul 2004 19:06:08 +0200 To: Schruefer Wolfgang X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Hi Wolfgang, it is not required that an SCTP implementation controls the source address. If the port number depends on the source address, then the SCTP implementation has to make that choice. Just one example. Best regards Michael On Jul 22, 2004, at 6:28 PM, Schruefer Wolfgang wrote: > Hi Michael, > > thanks for your comments, I can imagine your idea with association > identifiers could improve the procedure. > > But I do not unterstand your problems with the port numbers??? > Maybe we should distinguish between the local port number and the > remote port number: > > For this idea it is not necessary to change the local port number > handling! > The only change is that we have a different remote port number for > every path. > I think this should not cause difficulties, it is just an additional > entry in the local path variables? > > Please give an example if you still see serious problems. > > Thanks > Wolfgang > > > >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Thursday, July 22, 2004 5:24 PM >> To: Schruefer Wolfgang >> Cc: tsvwg@ietf.org >> Subject: Re: [Tsvwg] SCTP: alternative ADDIP to enable NAT for >> mulithoming >> >> >> Hi Wolfgang, >> >> I think it is very difficult to change the definition of an >> SCTP endpoint (at a given time) from a pair of a non-empty set >> of IP-address and a port number to a non-empty set of >> pair of IP-addresses and port numbers. >> >> However, if you only consider NAT boxes which translate IP-Addresses >> and and not port numbers than you have only to avoid transporting >> IP-addresses inside SCTP. >> >> You can do this by using an association identifier which you >> put into the INIT and INIT-ACK as a new parameter. This can be >> a hash to the TCB or something like this. >> >> Then you add a new chunk which acts like an ADD-IP but contains >> the association identifier instead of the old address. The receiver >> could find the association based on the association identifier and >> could add the source address as an additional path. >> >> Of course you would need to use the SCTP-AUTH extension to sign this >> new chunk, as it will be required for ADDIP. >> >> This would be a possible way do deal with NAT engines which do >> not look at port numbers and therefore should work with SCTP. >> >> This solution does not work with NAT engines which look at >> port numbers. But these boxes would need to support SCTP ... >> >> Best regards >> Michael >> >> On Jul 22, 2004, at 3:03 PM, Schruefer Wolfgang wrote: >> >>> Dear all, >>> >>> I want to suggest an alternative ADDIP procedure to enable >> multi-homed >>> SCTP associations through simple NAT boxes. Its goal is to >> avoid the >>> usage of address parameters within SCTP chunks. It is just an idea, >>> but up to now I see no restriction why it should not work ... >>> >>> >>> Example configuration: >>> Consider endpoint A (Client) has two local transport >> Adresses AL1 and >>> AL2. >>> Consider endpoint B (Server) has one or more global >> transport Adresses >>> B. >>> One or two simple NAT boxes translate addresses AL1 and AL2 >> to global >>> Adresses AG1 and AG2 (just IP-Address / Port). >>> >>> >>> Procedure: >>> >>> 1. Step: A establishes a first single-homed Association >> from AL1 to B. >>> >>> 2. Step: A establishes a second single-homed Association >> from AL2 to B. >>> >>> 3. Step: A requests B to merge the transport address of the second >>> assoc as new path for the first association. In parallel the second >>> association must be aborted. >>> >>> >>> >>> It could this be realized this way: >>> >>> 1) Definition of a new INIT/INIT-ACK parameter e.g. 'MERGE ONLY'. >>> Purpose: To mark the second association as temporarily used >> for ADDIP >>> (this association should not be used for data transport). >>> >>> 2) Definition of a new ASCONF (ADDIP) parameter e.g. 'MERGE SCTP >>> ENDPOINT'. >>> Purpose: To be sent via the first association to trigger the merger >>> (for security this parameter should contain at least the >> Verification >>> Tags of the second association, but not its transport address). >>> >>> 3) Removal of the Address Parameters in the ASCONF >> Paramters 'Delete >>> IP Address' and 'Set Primary IP Address'. >>> Remark: The source address of the packet including this >> chunk should >>> be used instead to identify the path. >>> >>> 4) Removal of the SCTP restriction: all path addresses must use the >>> same port number. >>> >>> >>> >>> Your comments are welcome! >>> >>> Viele Gruesse >>> Wolfgang >>> >>> _______________________________________________ >>> 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 Jul 23 05:13:34 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 FAA03416; Fri, 23 Jul 2004 05:13:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnw8D-0001eI-UF; Fri, 23 Jul 2004 05:14:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnw4g-0003LE-Oo; Fri, 23 Jul 2004 05:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnvtr-0007ua-BT for tsvwg@megatron.ietf.org; Fri, 23 Jul 2004 04:59: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 EAA02553 for ; Fri, 23 Jul 2004 04:59:29 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnvuX-0001QY-R1 for tsvwg@ietf.org; Fri, 23 Jul 2004 05:00:17 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i6N8xQ1j018198; Fri, 23 Jul 2004 10:59:26 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i6N8xQG03463; Fri, 23 Jul 2004 10:59:26 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i6N8xPU9016856; Fri, 23 Jul 2004 10:59:25 +0200 Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jul 2004 10:59:24 +0200 Message-ID: From: Schruefer Wolfgang To: "'Qiaobing Xie'" Subject: RE: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt Date: Fri, 23 Jul 2004 10:59:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: a7d6aff76b15f3f56fcb94490e1052e4 For multi-homed associations I think the described procedure has a problem if a NAT box manipulates the port number. Is it a restriction or am I wrong? Wolfgang > > All, > > I'd like to get your feedback on this I-D. Our intention is > to put together some guidelines > and information for people 1) who want to run SCTP across > NATs, and 2) who want to make > future NAT/middleboxes more SCTP friendly. > > regards, > -Qiaobing > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : SCTP NAT Transverse Considerations > > Author(s) : Q. Xie, et al. > > Filename : draft-xie-tsvwg-sctp-nat-00.txt > > Pages : 8 > > Date : 2004-7-14 > > > > This document provides guidelines and solutions for dealing > with SCTP > > association transversing NAT and similar middleboxes. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Jul 23 13:32: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 NAA10924; Fri, 23 Jul 2004 13:32:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo3v3-0002bn-MU; Fri, 23 Jul 2004 13:33:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo3qc-0002zH-Uk; Fri, 23 Jul 2004 13:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo3k4-0001aY-0j for tsvwg@megatron.ietf.org; Fri, 23 Jul 2004 13:21: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 NAA10336 for ; Fri, 23 Jul 2004 13:21:55 -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 1Bo3kr-0002SG-7H for tsvwg@ietf.org; Fri, 23 Jul 2004 13:22:46 -0400 Received: from [192.168.1.2] (pD9E56D11.dip.t-dialin.net [217.229.109.17]) by ilsa.franken.de (Postfix) with ESMTP id 3B1B5245CB; Fri, 23 Jul 2004 19:18:44 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt Date: Fri, 23 Jul 2004 19:21:45 +0200 To: Schruefer Wolfgang X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit I think he is talking about NAT (which only affects IP addresses) and not about NAPT (which affect IP addresses and port numbers). But just my guess... Best regards Michael On Jul 23, 2004, at 10:59 AM, Schruefer Wolfgang wrote: > For multi-homed associations I think the described procedure has a > problem if a NAT box manipulates the port number. > Is it a restriction or am I wrong? > > Wolfgang > > >> >> All, >> >> I'd like to get your feedback on this I-D. Our intention is >> to put together some guidelines >> and information for people 1) who want to run SCTP across >> NATs, and 2) who want to make >> future NAT/middleboxes more SCTP friendly. >> >> regards, >> -Qiaobing >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : SCTP NAT Transverse Considerations >>> Author(s) : Q. Xie, et al. >>> Filename : draft-xie-tsvwg-sctp-nat-00.txt >>> Pages : 8 >>> Date : 2004-7-14 >>> >>> This document provides guidelines and solutions for dealing >> with SCTP >>> association transversing NAT and similar middleboxes. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt >>> >> > > _______________________________________________ > 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 Jul 23 14:37: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 OAA17014; Fri, 23 Jul 2004 14:37:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo4vb-00040t-Hf; Fri, 23 Jul 2004 14:37:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo4qN-0004my-Eh; Fri, 23 Jul 2004 14:32:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo4gt-00027j-5n for tsvwg@megatron.ietf.org; Fri, 23 Jul 2004 14:22:43 -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 OAA15932 for ; Fri, 23 Jul 2004 14:22:41 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo4he-0003jz-Gm for tsvwg@ietf.org; Fri, 23 Jul 2004 14:23:33 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i6NIMbEs013045; Fri, 23 Jul 2004 11:22:37 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i6NIF8Rh027493; Fri, 23 Jul 2004 13:15:09 -0500 Message-ID: <410157B4.10602@motorola.com> Date: Fri, 23 Jul 2004 13:23:48 -0500 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: Michael Tuexen Subject: Re: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Schruefer Wolfgang , 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: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Yes, the description right now is focused on NAT only. Enhancement of the text will be needed to address NAPT properly. regards, -Qiaobing Michael Tuexen wrote: > I think he is talking about NAT (which only affects > IP addresses) and not about NAPT (which affect IP addresses > and port numbers). But just my guess... > > Best regards > Michael > > On Jul 23, 2004, at 10:59 AM, Schruefer Wolfgang wrote: > >> For multi-homed associations I think the described procedure has a >> problem if a NAT box manipulates the port number. >> Is it a restriction or am I wrong? >> >> Wolfgang >> >> >>> >>> All, >>> >>> I'd like to get your feedback on this I-D. Our intention is >>> to put together some guidelines >>> and information for people 1) who want to run SCTP across >>> NATs, and 2) who want to make >>> future NAT/middleboxes more SCTP friendly. >>> >>> regards, >>> -Qiaobing >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : SCTP NAT Transverse Considerations >>>> Author(s) : Q. Xie, et al. >>>> Filename : draft-xie-tsvwg-sctp-nat-00.txt >>>> Pages : 8 >>>> Date : 2004-7-14 >>>> >>>> This document provides guidelines and solutions for dealing >>> >>> with SCTP >>> >>>> association transversing NAT and similar middleboxes. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt >>>> >>> >> >> _______________________________________________ >> 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 Jul 23 17:01:17 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 RAA27121; Fri, 23 Jul 2004 17:01:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo7BD-0006g8-At; Fri, 23 Jul 2004 17:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo78G-0005t4-0L; Fri, 23 Jul 2004 16:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo72o-0004S4-RI for tsvwg@megatron.ietf.org; Fri, 23 Jul 2004 16:53:30 -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 QAA26817 for ; Fri, 23 Jul 2004 16:53:28 -0400 (EDT) Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo73e-0006ay-Hc for tsvwg@ietf.org; Fri, 23 Jul 2004 16:54:23 -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 i6NKqqN20882 for ; Fri, 23 Jul 2004 13:52:52 -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 MX274CF1; Fri, 23 Jul 2004 13:52:52 -0700 Received: from KCHAN-2K3.nortelnetworks.com (kchan-2k3.us.nortel.com [47.16.72.116]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PKX20VHS; Fri, 23 Jul 2004 16:52:50 -0400 Message-Id: <6.0.3.0.0.20040723165006.049f7018@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 23 Jul 2004 16:52:50 -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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: vfiroiu@nortelnetworks.com, Jozef Z Babiarz , Kwok Ho Chan Subject: [Tsvwg] Fwd: I-D ACTION:draft-babiarz-tsvwg-rtecn-01.txt 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: 6d95a152022472c7d6cdf886a0424dc6 Please review and provide any comments via tsvwg list or directly as you see fit. Thanks in advance! -- Kwok Ho Chan, Jozef Babiarz, Victor Firoiu -- >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Tue, 20 Jul 2004 15:50:22 -0400 >Subject: I-D ACTION:draft-babiarz-tsvwg-rtecn-01.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-SMTP-HELO: megatron.ietf.org >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org >X-SMTP-RCPT-TO: >audet@nortelnetworks.com,aceler@nortelnetworks.com,mbarnes@nortelnetworks.com,ldiburro@nortelnetworks.com,khchan@nortelnetworks.com,fiffi@nortelnetworks.com,schavali@nortelnetworks.com,ricagni@nortelnetworks.com,schishol@nortelnetworks.com,orton@nortelnetworks.com,mohand@nortelnetworks.com,tbastian@nortelnetworks.com,gkenward@nortelnetworks.com,seemery@nortelnetworks.com,jmfenart@nortelnetworks.com,jkwong@nortelnetworks.com,gww@nortelnetworks.com,gustavoa@nortelnetworks.com >X-SMTP-PEER-INFO: megatron.ietf.org [132.151.6.71] > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Congestion Notification Process for Real-Time > Traffic > Author(s) : J. Babiarz, et al. > Filename : draft-babiarz-tsvwg-rtecn-01.txt > Pages : 13 > Date : 2004-7-20 > >This memo specifies the usage of Explicit Congestion Notifications > (ECN) markings for real-time flows that use UDP, such as voice, video > conferencing and multimedia streaming. This memo tries to reuse as > much of RFC 3168, "The Addition of Explicit Congestion Notification > to IP", as possible. However, we found it necessary to introduce new > ECN semantics for real-time UDP flows. For real-time UDP flows, this > memo describes how the network performs ECN marking when congestion > is experienced, but it is left up to the application designers to > define how end systems should react to ECN bit marking. For > illustration purpose, an example is provided showing how ECN for > real-time UDP flows can be used for admission control of VoIP flows. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-01.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-babiarz-tsvwg-rtecn-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-babiarz-tsvwg-rtecn-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2004-7-20155423.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-babiarz-tsvwg-rtecn-01.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Jul 28 11:50: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 LAA08796; Wed, 28 Jul 2004 11:50:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpqjT-0000gr-8L; Wed, 28 Jul 2004 11:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpqZZ-0005oy-Qo; Wed, 28 Jul 2004 11:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpqUC-0004ug-5b for tsvwg@megatron.ietf.org; Wed, 28 Jul 2004 11:36: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 LAA07791 for ; Wed, 28 Jul 2004 11:36:53 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpqW0-0000SX-QJ for tsvwg@ietf.org; Wed, 28 Jul 2004 11:38:50 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6SFaKdn467844 for ; Wed, 28 Jul 2004 11:36:20 -0400 Received: from d03nm118.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6SFaJav185836 for ; Wed, 28 Jul 2004 09:36:20 -0600 To: tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Wed, 28 Jul 2004 09:36:13 -0600 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 07/28/2004 11:36:14 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 07/28/2004 11:36:14 AM, Serialize complete at 07/28/2004 11:36:14 AM, S/MIME Sign failed at 07/28/2004 11:36:14 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 07/28/2004 09:36:20, Serialize complete at 07/28/2004 09:36:20 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Dinakaran Joseph Subject: [Tsvwg] TCP-ESTATS-MIB - any discussion at 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: , Content-Type: multipart/mixed; boundary="===============1234381429==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multipart message in MIME format. --===============1234381429== Content-Type: multipart/alternative; boundary="=_alternative 0055B71B85256EDF_=" This is a multipart message in MIME format. --=_alternative 0055B71B85256EDF_= Content-Type: text/plain; charset="US-ASCII" Hello, I realize that there is a new draft of the TCP-ESTATS-MIB which was announced on 7/19. Will there be any discussion of this MIB module at the IETF tsvwg session next week? Thanks, Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Internet e-mail:adamson@us.ibm.com --=_alternative 0055B71B85256EDF_= Content-Type: text/html; charset="US-ASCII"
Hello,
   I realize that there is a new draft of the TCP-ESTATS-MIB which was announced on 7/19.  Will there be any discussion of this MIB module at the IETF tsvwg session next week?  Thanks,

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:adamson@us.ibm.com
 --=_alternative 0055B71B85256EDF_=-- --===============1234381429== 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 --===============1234381429==-- From tsvwg-bounces@ietf.org Wed Jul 28 12:42:48 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 MAA14528; Wed, 28 Jul 2004 12:42:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BprXp-0001yp-QQ; Wed, 28 Jul 2004 12:44:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BprDC-0006Lz-6f; Wed, 28 Jul 2004 12:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpr92-00051f-Pv for tsvwg@megatron.ietf.org; Wed, 28 Jul 2004 12:19: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 MAA12523 for ; Wed, 28 Jul 2004 12:19:06 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BprAt-0001Sd-Cm for tsvwg@ietf.org; Wed, 28 Jul 2004 12:21:03 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6SGIadn509802 for ; Wed, 28 Jul 2004 12:18:36 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6SGIaig396626 for ; Wed, 28 Jul 2004 10:18:36 -0600 To: tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Wed, 28 Jul 2004 10:18:33 -0600 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 07/28/2004 12:18:34 PM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 07/28/2004 12:18:34 PM, Serialize complete at 07/28/2004 12:18:34 PM, S/MIME Sign failed at 07/28/2004 12:18:34 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 07/28/2004 10:18:36, Serialize complete at 07/28/2004 10:18:36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Tsvwg] TCP-ESTATS-MIB: 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: , Content-Type: multipart/mixed; boundary="===============1206004980==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multipart message in MIME format. --===============1206004980== Content-Type: multipart/alternative; boundary="=_alternative 0059971285256EDF_=" This is a multipart message in MIME format. --=_alternative 0059971285256EDF_= Content-Type: text/plain; charset="US-ASCII" 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 --=_alternative 0059971285256EDF_= Content-Type: text/html; charset="US-ASCII"
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
 --=_alternative 0059971285256EDF_=-- --===============1206004980== 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 --===============1206004980==-- From tsvwg-bounces@ietf.org Fri Jul 30 22:03: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 WAA15839; Fri, 30 Jul 2004 22:03:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqjFr-00010D-NI; Fri, 30 Jul 2004 22:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqjAW-0000Ru-EE; Fri, 30 Jul 2004 22:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqj3J-0007jQ-69 for tsvwg@megatron.ietf.org; Fri, 30 Jul 2004 21:52:49 -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 VAA15536 for ; Fri, 30 Jul 2004 21:52:47 -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 1Bqj5d-0000ul-UX for tsvwg@ietf.org; Fri, 30 Jul 2004 21:55:15 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2004 18:53:52 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6V1qEtn021728 for ; Fri, 30 Jul 2004 18:52:15 -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 SAA19103 for ; Fri, 30 Jul 2004 18:52:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20040730205026.026f9ea0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jul 2004 20:52:55 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Tsvwg] Is there an Agenda posted for the 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: 2.3 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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