Re: [Tsvwg] SCTP: new chunks definition
Randall Stewart <rrs@lakerest.net> Mon, 02 March 2009 14:09 UTC
Return-Path: <rrs@lakerest.net>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E38E3A6861 for <tsvwg@core3.amsl.com>; Mon, 2 Mar 2009 06:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QvM0OxMLfyS for <tsvwg@core3.amsl.com>; Mon, 2 Mar 2009 06:09:14 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 0609E3A67E1 for <tsvwg@ietf.org>; Mon, 2 Mar 2009 06:09:13 -0800 (PST)
Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n22E9jg2020008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Mar 2009 09:09:46 -0500 (EST) (envelope-from rrs@lakerest.net)
Message-Id: <85201008-04C3-497F-A9BF-2C960B7D080E@lakerest.net>
From: Randall Stewart <rrs@lakerest.net>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <345F8ADB-42B3-4283-ADFD-AB0880BAB5E7@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 02 Mar 2009 09:09:35 -0500
References: <296afac70903012356y6dd06d13s7a06a75d7dbb5417@mail.gmail.com> <406B9630-F52C-456A-9062-AB1D2BB65804@lakerest.net> <296afac70903020546j4cf83fc0o4eb1292dc03f7b4e@mail.gmail.com> <345F8ADB-42B3-4283-ADFD-AB0880BAB5E7@lurchi.franken.de>
X-Mailer: Apple Mail (2.930.3)
Cc: Andrey Konstantinov <avkonst@gmail.com>, tsvwg@ietf.org
Subject: Re: [Tsvwg] SCTP: new chunks definition
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 14:09:15 -0000
Opps. It appears my posting are not going .. need to get the right from email address.. Bottom line.. Yes I agree with Michael and Brian here. We would need a far vaster understanding of why one would want to do this. It does not make sense to me.. I am sure there is more to it then just the desire not to implement a hash table... Andrey is most welcome to write a draft on the subject. But I don't think he will find support in the SCTP community without more details.. Regards R On Mar 2, 2009, at 8:50 AM, Michael Tüxen wrote: > On Mar 2, 2009, at 2:46 PM, Andrey Konstantinov wrote: > >> Hi, >> >> If extend it for V-Tag resetting it could suit... > The problem remains: Why do you want this? > Without having a good reason why you want to change > the v-tag, I hesitating to put that into an ID. > It might be a good thing (then I would support adding > it), it might be a bad thing... Currently I see no > good reason why you want to change the v-tag... > > Randy? >> >> Thanks, I'll take it into account. >> >> Best regards, >> Andrey Konstantinov >> >> 2009/3/2 Randy Stewart <randall@lakerest.net>: >>> Andrey: >>> >>> Please go take a close examination of: >>> >>> http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpstrrst-01.txt >>> >>> >>> This already has a mechanism to do some of the things you are >>> interested in I think. >>> >>> R >>> On Mar 2, 2009, at 2:56 AM, Andrey Konstantinov wrote: >>> >>>> Dear experts, >>>> >>>> I am looking for the possibility to change local V-Tag of the >>>> association in run time without it's restart. >>>> >>>> The idea of the extension is following: >>>> Local SCTP asks remote SCTP to change V-Tag (firstly defined by >>>> local >>>> side during start-up). >>>> I guess new chunk should be defined for this purpose. Remote side >>>> changes it and acknowledges the operation with help of another new >>>> chunk. >>>> INIT and INIT_ACK chunks are extended in order to negotiate >>>> support of >>>> the feature during start-up. >>>> >>>> Could you point me out to a RFC or draft if a similar extension of >>>> SCTP has been already defined? >>>> >>>> If I am the first with such type of request could you provide me >>>> input >>>> information how can we register, develop, review and approve this >>>> extension with IETF? >>>> The company which will possibly drive the development of the >>>> extension >>>> is Ericsson and/or Tieto. >>>> >>>> Thanks in advance, >>>> Andrey Konstantinov >>>> >>> >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>> >>> >>> >>> >>> >> > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
- [Tsvwg] SCTP: new chunks definition Andrey Konstantinov
- Re: [Tsvwg] SCTP: new chunks definition Michael Tüxen
- Re: [Tsvwg] SCTP: new chunks definition Andrey Konstantinov
- Re: [Tsvwg] SCTP: new chunks definition Brian F. G. Bidulock
- Re: [Tsvwg] SCTP: new chunks definition Andrey Konstantinov
- Re: [Tsvwg] SCTP: new chunks definition Michael Tüxen
- Re: [Tsvwg] SCTP: new chunks definition Andrey Konstantinov
- Re: [Tsvwg] SCTP: new chunks definition Michael Tüxen
- Re: [Tsvwg] SCTP: new chunks definition Brian F. G. Bidulock
- Re: [Tsvwg] SCTP: new chunks definition Randall Stewart
- Re: [Tsvwg] SCTP: new chunks definition Caitlin Bestler
- Re: [Tsvwg] SCTP: new chunks definition Michael Tüxen
- Re: [Tsvwg] SCTP: new chunks definition Caitlin Bestler
- Re: [Tsvwg] SCTP: new chunks definition Michael Tüxen