IETF Logo Mail Archive

Re: [tcpm] Erik Kline's Yes on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 30 September 2021 19:56 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99493A10EF; Thu, 30 Sep 2021 12:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G95jjdaBzLfS; Thu, 30 Sep 2021 12:55:56 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7C93A10EE; Thu, 30 Sep 2021 12:55:55 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18UJtd57005688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 15:55:44 -0400
Date: Thu, 30 Sep 2021 12:55:39 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Erik Kline <ek.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpm-rfc793bis@ietf.org, tcpm@ietf.org, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org
Message-ID: <20210930195539.GP98042@kduck.mit.edu>
References: <163210010379.32567.16863104514639344723@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <163210010379.32567.16863104514639344723@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/lZTP7pHUMJ05kCn8-E_tn_26NTQ>
Subject: Re: [tcpm] Erik Kline's Yes on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2021 19:56:01 -0000

On Sun, Sep 19, 2021 at 06:08:23PM -0700, Erik Kline via Datatracker wrote:
[...]
> [S3.5, question]
> 
> * Is there an example of what possible use a RST w/ data could serve?
> 
>   I didn't see anything in S3.10.7(.*) that indicated the data in a segment
>   with the RST flag set could get processed (I may have missed it).

Section 4.2.2.12 of RFC 1122 (sorry, the section link doesn't work, though
https://www.rfc-editor.org/rfc/rfc1122.html#page-87 gets most of the way
there) has:

            A TCP SHOULD allow a received RST segment to include data.

            DISCUSSION
                 It has been suggested that a RST segment could contain
                 ASCII text that encoded and explained the cause of the
                 RST.  No standard has yet been established for such
                 data.

-Ben

v2.23.0 | Report a Bug | By Email