Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)

"Black, David" <David.Black@dell.com> Mon, 13 April 2020 00:30 UTC

Return-Path: <David.Black@dell.com>
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 2AC953A0D86 for <tsvwg@ietfa.amsl.com>; Sun, 12 Apr 2020 17:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=B5gHda/O; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=l2Z3Xre0
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 G7RbXXZXJhi6 for <tsvwg@ietfa.amsl.com>; Sun, 12 Apr 2020 17:30:01 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 7CE973A0D85 for <tsvwg@ietf.org>; Sun, 12 Apr 2020 17:30:01 -0700 (PDT)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03D0Hc4n007473; Sun, 12 Apr 2020 20:29:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=Hd4LdEVYo1kR3Dm4SC/EMPAb5jhNJ+NDfaDN99NTzMw=; b=B5gHda/OVX9m5GFdoz4/khL31XLaWI3LryVDbokQsgw8R1tavGUq4w9YrNhXLpHK17q4 dtBzrciJo/spQKxJsPXvT0JLSc0EZALCd0B5L7QKvHJ1tejlXoXUWlohsFXEr+I/PASk qv/DXF+5saxsnvOnXTeEm1j8YBVsNhwROHYdP6e2MnCQAw5wWLFrSoNixBk6naiYulix WntQhNaprJe6PI6VqRWYv6yt9zi6YgHYc4ZgntVdiiO+VgINTEJ7HgbG6hpWo/pHpPEm 37vs4N3rJ6/hha0Ilru3t5yJrLr0syJrBi2EcBfA7JsRvzk8D++e8lA/OAF8JlJIJcp5 sQ==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 30b9qyy3g0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Apr 2020 20:29:45 -0400
Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03D0RnEv062168; Sun, 12 Apr 2020 20:29:45 -0400
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2171.outbound.protection.outlook.com [104.47.56.171]) by mx0b-00154901.pphosted.com with ESMTP id 30b8eagw35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 12 Apr 2020 20:29:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+D8HWzeS8XyE05aQsoYxM32mZop47GKGPxYI1Z7YovY89jv3s7ChbyX/HJTAtrc7zqhkFGOkPcGZ1w48PI3DNWPzGDe8xEW4BG79Jz/bzyrVkEJ6olfgOd9H2tAMyhulOQdD4kja3Hk3i+KeF0QApwJyoLkDhHmn/dhSJi4xY/5zVEVmWGQnniRk9qHjZPKUaXVQvuW+Qh2IfhjGc9ZBOmjaOnGhwYA/r7aDfLOq2HQP5nZq3qoB2fZ3kBlD1a9Js/4T3OJhEJIOL3AGLsoWey/veiGh5zyG0oddAizHtLOkPfFditIP8dwVQbx+XwKeocCBktgB+wNjLFi5owyIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hd4LdEVYo1kR3Dm4SC/EMPAb5jhNJ+NDfaDN99NTzMw=; b=d0XM768XO5D+6S80Y7OScY0ma/jzTGWiwSdQDo3HQlCeGa8ytwsZAznezKd5+WS+2lh9Z/hy8/u5OEz2zsY+z60ts8vNA09G3sx5BGRF5L7Z9Vn/v72pz2s1liYOQAsEwsZPIiKnL6vV6JrVdmYRvZ6ZU42/9EZTHlOqnvKnE9+T15Oy9uGbowBmgzpqE/cyncvB4j/2Bo7cSR1ICHX+eb5czqPlfrTeX5nlFdAsmzI5NGd22LwRHjohuMVaRVLQyQ/O+33u8gQrLCbgYqrJvxk94OBSp/ioMw94bG77I6nV7dbeVJ/GuQYvfWyO0xAwRI0uMndoboYqqIl8nroQWA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hd4LdEVYo1kR3Dm4SC/EMPAb5jhNJ+NDfaDN99NTzMw=; b=l2Z3Xre0POcz+gpBZLfEU0HOKWASoAaeBVZSs6lpZOlhqpR2RZntD89+emqOGY7pFKG7SYm3oyUpZ8tHo0wfk7h0qYmQ8M/beEDCkOrkDxe1/oTT+A3YjejclQuIPUCX/bEHKrOb/RnL4BizRnLb4KyTvw6KqVOHQwnYZiWxcs4=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3917.namprd19.prod.outlook.com (2603:10b6:208:1e3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Mon, 13 Apr 2020 00:29:42 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2900.026; Mon, 13 Apr 2020 00:29:42 +0000
From: "Black, David" <David.Black@dell.com>
To: Michael Tuexen <tuexen@fh-muenster.de>, =?utf-8?B?546L56S86bmk?= <wanglihe@ebupt.com>
CC: randall <randall@lakerest.net>, Kacheong Poon <ka-cheong.poon@oracle.com>, Peter Lei <peterlei@cisco.com>, vladislav.yasevich <vladislav.yasevich@hp.com>, martin.h.duke <martin.h.duke@gmail.com>, magnus.westerlund <magnus.westerlund@ericsson.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, wes <wes@mti-systems.com>, tsvwg <tsvwg@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
Thread-Index: AQHWDio/ico5KhgfPEyNjwgFk1qOFahxUpoAgAKVHACAACn2gIACJfIg
Date: Mon, 13 Apr 2020 00:29:42 +0000
Message-ID: <MN2PR19MB4045989A4FFA74C30ECE2CBB83DD0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <20200409044654.2FBA6F4070F@rfc-editor.org> <B5F6CD48-D7C5-477C-894C-F0CC2574BF83@fh-muenster.de> <tencent_77F6CC616D2D4B1B5B143A4C@qq.com> <FA3EDE54-C951-4220-8677-6D9EAFD9C412@fh-muenster.de>
In-Reply-To: <FA3EDE54-C951-4220-8677-6D9EAFD9C412@fh-muenster.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_Enabled=True; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_Owner=david.black@emc.com; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_SetDate=2020-04-13T00:29:40.2961876Z; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_Name=Customer Communication; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_Application=Microsoft Azure Information Protection; MSIP_Label_a17f17c0-b23c-493d-99ab-b037779ecd33_Extended_MSFT_Method=Manual; aiplabel=Customer Communication
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4b7a0a09-f3b8-4976-3a72-08d7df41c2ac
x-ms-traffictypediagnostic: MN2PR19MB3917:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB391782BB128670B408A8C6A083DD0@MN2PR19MB3917.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(136003)(366004)(346002)(396003)(39860400002)(478600001)(8936002)(186003)(966005)(81156014)(8676002)(86362001)(2906002)(71200400001)(26005)(4326008)(5660300002)(66476007)(786003)(316002)(66446008)(66556008)(107886003)(9686003)(55016002)(54906003)(53546011)(6506007)(52536014)(110136005)(567974003)(7416002)(33656002)(7696005)(76116006)(64756008)(66946007)(493334003); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EkcKJjNdAY1po6ZbeSYF0+OVD53j473h/A8zDMkODG1aMT/fRSnhIdbSnezXxYDHKilFgX6nI2afaA2W0QzgIHD9x4XltJ7YjEMP5GDVDHq6YjS2B5+Rr4/XpV0HvNqPbqPzFvBcMvhOEr9lY+m+W4LwgdQfxrIV2e3Gwfr8pLK9abHumfTPBH0Qa5PgP016FmL+1IH3XIEb2Byl2fOb7ipiOQhVtUuLfeq6uAjq1qcrdA1M7d793sFK5V5N1f+jO9K02le5h1ufR/NKjCkgmysR3LONJ5vT8bDM5I5ruCmfCwyjlbYseu1C4pQdW4mst0/0qYbi1IOCAcU7gHcD3b5LeIH+VyLKHr3MCKBnq4l85PrYQ6zPYavJUlZQ1D1PefllGYE4AGnpreEXWKpI0jeuJxYjh0bruKJILFncB3Bmsyoeoh9ucGtJyfDfv5xWhrOrmDZdCmk2/0/CMNivImaaN56lK/jscf0uteuKijhuVp4GwLFUALEHa/hzBJa3uJ40BkirdKDUs16FDpyHgH9bSYxGSjwEHmU4VLiG6DD/vmyW+/gvVB+GUYhgTQgt+Y597IWXMBDJOT2viXrfWQ==
x-ms-exchange-antispam-messagedata: hmdMxehyWo5aywejES9hKTNPQrNSZxYCMlxjmu25bB4dVC3zq/1nHzKbOI8iqQbOAMmH0097OHbnr7AER9eZRSXmYKDktY0mNE6lPPjRDxMTXeQqB2JF23Npwsr8ZY5qCEBYYlVTggbhZNs13nzSDg==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b7a0a09-f3b8-4976-3a72-08d7df41c2ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2020 00:29:42.6078 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xM16Qg/td0c4tLiuiEHOhoH+UX7EfLBHFE50+WrIZoDC+ystSXMM+q+roztdl8PpvbRjKLIvU64hVdh7OV50xQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3917
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-12_11:2020-04-12, 2020-04-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1011 suspectscore=0 phishscore=0 mlxlogscore=999 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004130002
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004130001
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ebTLQ6R1edw1v3h7lNPlB8HukuM>
Subject: Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
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, 13 Apr 2020 00:30:04 -0000

Dell Customer Communication - Confidential

Michael,

> > Will you update these two words
> > > It can be used in the snd_flags field of the sctp_sndinfo structure.
> > > It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure.
> > to the RFC 6458 or Errata?
> 
> An RFC can't be changed and I can't change the Errata you submitted. All I can do
> is to respond to emails. Possibly an AD can edit an Errata, I don't know.
> If it is useful, I can submit an e-mail with text using the OLD TEXT/NEW TEXT
> way.

Actually, there is something else that can be done - submit an additional Errata that contains just the set of changes that have been agreed to here.  Then that new additional Errata can be accepted (might take the form of Held for Document Update), after which the original Errata rejected with a note that the concern is addressed by the new additional Errata.

Thanks, --David

> -----Original Message-----
> From: Michael Tuexen <tuexen@fh-muenster.de>
> Sent: Saturday, April 11, 2020 11:37 AM
> To: 王礼鹤
> Cc: randall; Kacheong Poon; Peter Lei; vladislav.yasevich; martin.h.duke;
> magnus.westerlund; Black, David; Gorry Fairhurst; wes; tsvwg; RFC Errata
> System
> Subject: Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
> 
> > On 11. Apr 2020, at 15:06, 王礼鹤 <wanglihe@ebupt.com> wrote:
> >
> > Thank you for reply.
> >
> > Will you update these two words
> > > It can be used in the snd_flags field of the sctp_sndinfo structure.
> > > It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure.
> > to the RFC 6458 or Errata?
> An RFC can't be changed and I can't change the Errata you submitted. All I can do
> is to respond to emails. Possibly an AD can edit an Errata, I don't know.
> If it is useful, I can submit an e-mail with text using the OLD TEXT/NEW TEXT
> way.
> >
> > And
> >
> > for receiver, I agree  that MSG_EOR is enough to detect a whole message in
> a
> > stream, but for sender(SCTP_EOR is only for sender) it is more complex. If
> user
> I agree, MSG_EOR is only relevant on the receiver side, SCTP_EOR on the
> sender side.
> > space decide which is EOR and kernel space decide which is INIT, every
> stream
> > must record the stream status. When kernel get a EOR, it must be set to INIT
> after
> Yes, for each outgoing stream you need to keep some state around.
> > send packet. Think about this, at worst, kernel have to record 65535 streams,
> it
> > is lots of memory. And at a speical time, change SCTP_EXPLICIT_EOR status,
> for
> That is why you can negotiate the number of streams at the beginning of the
> association.
> You can also to late allocation, but once all streams have been used you need
> to have some state.And yes, you need to keep a flag if the last message was
> complete.
> > some implement, it got a flood of SCTP_EOR message, 65535 pieces.
> What happens if you turn off the SCTP_EXPLICIT_EOR mode is implementation
> dependent.
> I haven't used it in a way that it is dynamically turned on and off, but the
> specification
> does not disallow this. But I don't see a problem if an implementation simply
> would
> not support it and return an error.
> >
> > So, for sender, I think it should all decide by userspace, INIT or EOR, then
> > kernel will have clean code, just like send fragments. While if got INIT error,
> > receiver can simply drop a non-INIT chunk when buffer is empty, or drop
> buffer
> > when get a INIT chunk, very easy.
> I don't agree here. SCTP is a reliable transport layer and the receiver should
> not
> discard user messages with ABORTing the association.
> 
> So I agree, you have to keep state for each outgoing stream, but you have to do
> it
> anyway. It is just one bit more for knowing if the last message was terminated.
> 
> Best regards
> Michael
> >
> >
> > ------------------
> > 王礼鹤
> > 公司/东信北邮/5G多媒体产品中心/媒体产品部
> > 15210985877
> > 北京市海淀区知春路9号坤讯大厦
> > 此电子邮件包含来自东信北邮的信息,而且是机密的或者专用的信息,
> 仅供标明地址的个人或团体使用。如果您收到的电子邮件存在错误,请通
> 知本公司,删除全部原始信息(包括任何原始信息的备份),并且禁止散
> 布或分发全部或部分原始信息。本公司不担保本电子邮件中信息的准确性
> 、适当性或完整性,并且对此产生的任何错误或疏忽不承担任何责任。接
> 收方应在接收电子邮件或任何附件时检查有无病毒。本公司对由于转载本
> 电子邮件而引发病毒产生的任何损坏不承担任何责任。 爱护环境 善用纸
> 张 打印文件 必先三思。
> >
> >
> >
> > ------------------ Original ------------------
> > From:  "Michael Tuexen"<tuexen@fh-muenster.de>ster.de>;
> > Date:  Fri, Apr 10, 2020 05:40 AM
> > To:  "RFC Errata System"<rfc-editor@rfc-editor.org>tor.org>;
> > Cc:  "randall"<randall@lakerest.net>lakerest.net>; "Kacheong Poon"<ka-
> cheong.poon@oracle.com>gt;; "Peter Lei"<peterlei@cisco.com>sco.com>;
> "vladislav.yasevich"<vladislav.yasevich@hp.com>evich@hp.com>;
> "martin.h.duke"<martin.h.duke@gmail.com>ke@gmail.com>;
> "magnus.westerlund"<magnus.westerlund@ericsson.com>ericsson.com>;
> "david.black"<david.black@dell.com>ack@dell.com>; "Gorry
> Fairhurst"<gorry@erg.abdn.ac.uk>n.ac.uk>; "wes"<wes@mti-systems.com>-systems.com>;
> "wanglihe"<wanglihe@ebupt.com>he@ebupt.com>; "tsvwg"<tsvwg@ietf.org>vwg@ietf.org>;
> > Subject:  Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
> >
> > > On 9. Apr 2020, at 06:46, RFC Errata System <rfc-editor@rfc-editor.org>
> wrote:
> > >
> > > 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/eid6081
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: wanglihe <wanglihe@ebupt.com>
> > >
> > > Section: GLOBAL
> > >
> > > Original Text
> > > -------------
> > > 8.1.26    must indicate that they are
> > >   finished sending a particular record by including the SCTP_EOR flag.
> > >
> > > but I can not find where to use SCTP_EOR flag.
> > >
> > > because
> > >
> > > 5.1  The msg_flags are not used when sending a message with sendmsg().
> > >
> > > 3.1.4  flags:  No new flags are defined for SCTP at this level.  See
> > >      Section 5 for SCTP-specific flags used in the msghdr structure.
> > >
> > > 4.1.8 same with 3.1.4
> > >
> > > 9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
> > >      MSG_DONTROUTE).
> > >
> > > 9.7   flags:  The same as sinfo_flags (see Section 5.3.2).
> > >
> > > 5.3.2 sinfo_flags not mention about it
> > >
> > > Corrected Text
> > > --------------
> > > maybe msg_flags should be used.
> > I agree, that text describing where to use the SCTP_EOR flag is missing.
> >
> > It can be used in the snd_flags field of the sctp_sndinfo structure.
> > It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure,
> > which is deprecated.
> > >
> > > Notes
> > > -----
> > > Another problem is that, I think it should be discuss about debfine a flag like
> SCTP_BOR for beginning(init chunk) of a Record, because a stream of this
> socket(assoc) can still be used after send a SCTP_EOR.
> > I don't think this is needed, since if you know when a message ends, the next
> userdata on the same
> > stream with the same ordering property is the beginning.
> > >
> > > And between  a init chunk and  a STCP_EOR,  if I change
> SCTP_EXPLICIT_EOR status, what the socket will send the message?
> > What happens if you are have not completed to provide a complete message
> and you turn off SCTP_EXPLICIT_EOR
> > is not specified. An implementation could fail the disabling of
> SCTP_EXPLICIT_EOR, but I don't think the
> > BSD stack does this. I guess (not tested) it will terminate the current message
> with the next send call.
> >
> > Best regards
> > Michael
> > >
> > > 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
> > >
> >
> >