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

From: RFC Errata System <[email-masked]>
Date: Wed, 8 Apr 2020 21:46:54 -0700 (PDT)

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 <[email-masked]>

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.

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.

And between  a init chunk and  a STCP_EOR,  if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 9 Apr 2020 23:40:20 +0200

> On 9. Apr 2020, at 06:46, RFC Errata System <[email-masked]> wrote:
> 
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.
> 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…
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

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 11 Apr 2020 17:36:43 +0200

> On 11. Apr 2020, at 15:06, 王礼鹤 <[email-masked]> wrote:
> 
> Thank you for reply.
> 
> Will you update these two words
> > 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"<[email-masked]>;
> Date:  Fri, Apr 10, 2020 05:40 AM
> To:  "RFC Errata System"<[email-masked]>;
> Cc:  "randall"<[email-masked]>; "Kacheong Poon"<[email-masked]>; "Peter Lei"<[email-masked]>; "vladislav.yasevich"<[email-masked]>; "martin.h.duke"<[email-masked]>; "magnus.westerlund"<[email-masked]>; "david.black"<[email-masked]>; "Gorry Fairhurst"<[email-masked]>; "wes"<[email-masked]>; "wanglihe"<[email-masked]>; "tsvwg"<[email-masked]>;
> Subject:  Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
>

---

From: "王礼鹤" <[email-masked]>
Date: Sat, 11 Apr 2020 21:06:32 +0800

Thank you for reply.

Will you update these two words
&gt; It can be used in the snd_flags field of the sctp_sndinfo structure.
&gt; It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure.
to the RFC 6458 or Errata?

And 

for receiver, I agree&nbsp; that MSG_EOR is enough to detect a whole message in a 

------------------

王礼鹤

公司/东信北邮/5G多媒体产品中心/媒体产品部

15210985877

北京市海淀区知春路9号坤讯大厦

&nbsp;
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Michael Tuexen"<[email-masked]&gt;;
Date: &nbsp;Fri, Apr 10, 2020 05:40 AM
To: &nbsp;"RFC Errata System"<[email-masked]&gt;; 
Cc: &nbsp;"randall"<[email-masked]&gt;; "Kacheong Poon"<[email-masked]&gt;; "Peter Lei"<[email-masked]&gt;; "vladislav.yasevich"<[email-masked]&gt;; "martin.h.duke"<[email-masked]&gt;; "magnus.westerlund"<[email-masked]&gt;; "david.black"<[email-masked]&gt;; "Gorry Fairhurst"<[email-masked]&gt;; "wes"<[email-masked]&gt;; "wanglihe"<[email-masked]&gt;; "tsvwg"<[email-masked]&gt;; 
Subject: &nbsp;Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)

&nbsp;

&gt; On 9. Apr 2020, at 06:46, RFC Errata System <[email-masked]&gt; wrote:
&gt; 
&gt; The following errata report has been submitted for RFC6458,
&gt; "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)".
&gt; 
&gt; --------------------------------------
&gt; You may review the report below and at:
&gt; https://www.rfc-editor.org/errata/eid6081
&gt; 
&gt; --------------------------------------
&gt; Type: Technical
&gt; Reported by: wanglihe <[email-masked]&gt;
&gt; 
&gt; Section: GLOBAL
&gt; 
&gt; Original Text
&gt; -------------
&gt; 8.1.26&nbsp;&nbsp;&nbsp; must indicate that they are
&gt;&nbsp;&nbsp; finished sending a particular record by including the SCTP_EOR flag.
&gt; 
&gt; but I can not find where to use SCTP_EOR flag.
&gt; 
&gt; because
&gt; 
&gt; 5.1&nbsp; The msg_flags are not used when sending a message with sendmsg().
&gt; 
&gt; 3.1.4&nbsp; flags:&nbsp; No new flags are defined for SCTP at this level.&nbsp; See
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 5 for SCTP-specific flags used in the msghdr structure.
&gt; 
&gt; 4.1.8 same with 3.1.4
&gt; 
&gt; 9.10, 9.12&nbsp;&nbsp;&nbsp; flags:&nbsp; The same flags as used by the sendmsg() call flags (e.g.,
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MSG_DONTROUTE).
&gt; 
&gt; 9.7&nbsp;&nbsp; flags:&nbsp; The same as sinfo_flags (see Section 5.3.2).
&gt; 
&gt; 5.3.2 sinfo_flags not mention about it&nbsp; 
&gt; 
&gt; Corrected Text
&gt; --------------
&gt; 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.
&gt; 
&gt; Notes
&gt; -----
&gt; 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.
&gt; 
&gt; And between&nbsp; a init chunk and&nbsp; a STCP_EOR,&nbsp; 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
&gt; 
&gt; Instructions:
&gt; -------------
&gt; This erratum is currently posted as "Reported". If necessary, please
&gt; use "Reply All" to discuss whether it should be verified or
&gt; rejected. When a decision is reached, the verifying party&nbsp; 
&gt; can log in to change the status and edit the report, if necessary. 
&gt; 
&gt; --------------------------------------
&gt; RFC6458 (draft-ietf-tsvwg-sctpsocket-32)
&gt; --------------------------------------
&gt; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
&gt; Publication Date&nbsp;&nbsp;&nbsp; : December 2011
&gt; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich
&gt; Category&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : INFORMATIONAL
&gt; Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Transport Area Working Group
&gt; Area&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Transport
&gt; Stream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IETF
&gt; Verifying Party&nbsp;&nbsp;&nbsp;&nbsp; : IESG
&gt;

---

From: "Black, David" <[email-masked]>
Date: Mon, 13 Apr 2020 00:29:42 +0000

Dell Customer Communication - Confidential

Michael,

> If it is useful, I can submit an e-mail with text using the OLD TEXT/NEW TEXT

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 <[email-masked]>
> 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
> > 此电子邮件包含来自东信北邮的信息，而且是机密的或者专用的信息，
> 仅供标明地址的个人或团体使用。如果您收到的电子邮件存在错误，请通
> 知本公司，删除全部原始信息（包括任何原始信息的备份），并且禁止散
> 布或分发全部或部分原始信息。本公司不担保本电子邮件中信息的准确性
> 、适当性或完整性，并且对此产生的任何错误或疏忽不承担任何责任。接
> 收方应在接收电子邮件或任何附件时检查有无病毒。本公司对由于转载本
> 电子邮件而引发病毒产生的任何损坏不承担任何责任。 爱护环境 善用纸
> 张 打印文件 必先三思。
> >
> >
> >
> > Cc:  "randall"<[email-masked]>; "Kacheong Poon"<ka-
> [email-masked]>; "Peter Lei"<[email-masked]>;
> "vladislav.yasevich"<[email-masked]>;
> "martin.h.duke"<[email-masked]>;
> "magnus.westerlund"<[email-masked]>;
> "david.black"<[email-masked]>; "Gorry
> Fairhurst"<[email-masked]>; "wes"<[email-masked]>;
> "wanglihe"<[email-masked]>; "tsvwg"<[email-masked]>;
> > > 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.
> > > And between  a init chunk and  a STCP_EOR,  if I change
> SCTP_EXPLICIT_EOR status, what the socket will send the message?

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 13 Apr 2020 11:47:47 +0200

> On 13. Apr 2020, at 02:29, Black, David <[email-masked]> wrote:
> 
OK. I will do that.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 20 Apr 2020 15:18:05 +0200

> 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 
Done: https://www.rfc-editor.org/errata/eid6111

Best regards
Michael
> original Errata rejected with a note that the concern is addressed by the new additional Errata.
> 
> Thanks, --David
>

---

From: Megan Ferguson <[email-masked]>
Date: Tue, 21 Apr 2020 16:16:10 -0700

Greetings,

Would it be appropriate for us to delete errata report 6081 instead of someone rejecting it (that is, if errata 6111 now appears as you wanted)?   Please advise.

FYI - For future reference, we can update the text in errata reports as long as provided with old/new clearly described in email.

Thank you.

RFC Editor/mf

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 22 Apr 2020 01:24:28 +0200

> On 22. Apr 2020, at 01:16, Megan Ferguson <[email-masked]> wrote:
> 
> Greetings,
> 
6111 replaces the OLD/NEW part of 6081.

The author of 6081 mentions in the Notes:
(1) He want to define SCTP_BOR.
(2) He asks what should be done if the SCTP_EXPLICIT_EOR status is changed.

I think (1) should not be done.
One could clarify (2), but I would prefer to leave it implementation dependent.

Not sure what the best way to handle this is...
> FYI - For future reference, we can update the text in errata reports as long as provided with old/new clearly described in email.
OK. Good to know.

Best regards
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 Apr 2020 07:39:08 +0100

> Not sure what the best way to handle this is...

 From my side: If the WG has not reached consensus on an approach - then 
this will remain implementation dependent, someone can propose a new 
short draft to discuss this and we can then see if the WG has interest 
in trying to progress with as a change.

Gorry