[tsvwg] [Technical Errata Reported] RFC6458 (6111)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 20 April 2020 13:15 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 BE5843A0CCD for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 06:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 sdMiw_HYtHVh for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 06:15:53 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBB03A0CC8 for <tsvwg@ietf.org>; Mon, 20 Apr 2020 06:15:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id A8245F406CD; Mon, 20 Apr 2020 06:15:50 -0700 (PDT)
To: randall@lakerest.net, tuexen@fh-muenster.de, ka-cheong.poon@oracle.com, peterlei@cisco.com, vladislav.yasevich@hp.com, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, david.black@dell.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: tuexen@fh-muenster.de, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200420131550.A8245F406CD@rfc-editor.org>
Date: Mon, 20 Apr 2020 06:15:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pir0TAysx6jLMw4YdSNwqtQ0T9Y>
Subject: [tsvwg] [Technical Errata Reported] RFC6458 (6111)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 20 Apr 2020 13:15:57 -0000
The following errata report has been submitted for RFC6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6111 -------------------------------------- Type: Technical Reported by: Michael Tuexen <tuexen@fh-muenster.de> Section: GLOBAL Original Text ------------- in Section 5.3.2 SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedure on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association. SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to- one style socket, this flag has no effect. in Section 5.3.4 SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedures on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association. SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to-one style socket, this flag has no effect. in Section 8.1.13 The sinfo_flags field is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL. in Section 8.1.31 The snd_flags parameter is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL. Corrected Text -------------- in Section 5.3.2 SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedure on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association. SCTP_EOR: This flag, if set and explicit EOR marking (see Section 8.1.26) is enabled , indicates that the user data provided is the last part of a user message. If explicit EOR marking is disabled, this flag is not relevant, since the user data provided is a complete user message. SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to- one style socket, this flag has no effect. in Section 5.3.4 SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown procedures on the specified association. Graceful shutdown assures that all data queued by both endpoints is successfully transmitted before closing the association. SCTP_EOR: This flag, if set and explicit EOR marking (see Section 8.1.26) is enabled , indicates that the user data provided is the last part of a user message. If explicit EOR marking is disabled, this flag is not relevant, since the user data provided is a complete user message. SCTP_SENDALL: This flag, if set, will cause a one-to-many style socket to send the message to all associations that are currently established on this socket. For the one-to-one style socket, this flag has no effect. in Section 8.1.13 The sinfo_flags field is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL. in Section 8.1.31 The snd_flags parameter is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL. Notes ----- The text is missing a description of how to use the SCTP_EOR flag in the Socket API. The problem was initially reported by wanglihe in https://www.rfc-editor.org/errata/eid6081 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6458 (draft-ietf-tsvwg-sctpsocket-32) -------------------------------------- Title : Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) Publication Date : December 2011 Author(s) : R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich Category : INFORMATIONAL Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG
- [tsvwg] [Technical Errata Reported] RFC6458 (6111) RFC Errata System