Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1A521F8A58 for ; Wed, 24 Aug 2011 11:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRGlUd-8xRyC for ; Wed, 24 Aug 2011 11:46:38 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA15E21F89B8 for ; Wed, 24 Aug 2011 11:46:38 -0700 (PDT) Received: by iye1 with SMTP id 1so2275805iye.27 for ; Wed, 24 Aug 2011 11:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uJVN4j3wzn50+N2ZDAJq2ecqoOBpeIk3Y+Y3d0odXvQ=; b=Kn+Gtjk+bLdYO98XunXAYQ70v/wyMQQ2piE9cJueJ8HtT/di3GGGn5JDuAfYi6x5wI GT+0aTqOUkahqiXtS0HeFo+qSsunU3eDhBVtjG8DzZXwzWL6cfyCoX8/qS0SClfcsV45 h3Y9QBR7/y1yJQo1dgN4YR+oylFwTsOCRAXEQ= MIME-Version: 1.0 Received: by 10.231.47.17 with SMTP id l17mr6827289ibf.24.1314211669902; Wed, 24 Aug 2011 11:47:49 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Wed, 24 Aug 2011 11:47:49 -0700 (PDT) In-Reply-To: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de> References: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de> Date: Wed, 24 Aug 2011 11:47:49 -0700 X-Google-Sender-Auth: PykZo2XUm6TxCycqfI8Q2QrRfZs Message-ID: Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt From: Yoshifumi Nishida To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:46:39 -0000 2011/8/24 Michael T=FCxen : > On Aug 24, 2011, at 12:24 PM, Yoshifumi Nishida wrote: > >> Hi Michael, >> >> Thank you so much for the review. =A0Most points were addressed by Preet= hi. >> So, I just would like to clarify one point. >> >> 2011/8/22 Michael T=FCxen : >> >>> >>> =A0 o =A0When the sender receives an heartbeat ACK from a PF destinatio= n, >>> =A0 =A0 =A0the sender clears the destination's error counter and transi= tions >>> =A0 =A0 =A0the PF destination back to active state. =A0This state trans= ition >>> =A0 =A0 =A0MUST NOT be notified to the ULP unless it is explicitly requ= ested. >>> =A0 =A0 =A0This destination's cwnd is set to 1 MTU (TODO: or 2? =A0Need= s more >>> =A0 =A0 =A0text discussing rationale; can revisit later?) >>> >>> We don't have defined a notification. I don't see the value >>> of it. So maybe you want to get rid of it? >> >> Hmm. I might miss your point, but I believe we cannot use arbitrary valu= e.. >> Shall we refer 7.2.1 in RFC4960? > I was not clear... I'm referring to the sentence: > > This state transition MUST NOT be notified to the ULP unless it > is explicitly requested. > > Currently we do not have such a notification. That is why I'm asking, > if it would be better to remove it. Oh. I see. Make sense. Thanks for the clarification. Regards, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp