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

[Megan Ferguson <[e-mail]>]

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

On Apr 20, 2020, at 6:18 AM, Michael Tuexen <[e-mail]> wrote:

>> On 13. Apr 2020, at 02:29, Black, David <[e-mail]> wrote:
>> 
>> 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 
> 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
>> 
>>> -----Original Message-----
>>> From: Michael Tuexen <[e-mail]>
>>> 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, 王礼鹤 <[e-mail]> 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"<[e-mail]>;
>>>> Date:  Fri, Apr 10, 2020 05:40 AM
>>>> To:  "RFC Errata System"<[e-mail]>;
>>>> Cc:  "randall"<[e-mail]>; "Kacheong Poon"<ka-
>>> [e-mail]>; "Peter Lei"<[e-mail]>;
>>> "vladislav.yasevich"<[e-mail]>;
>>> "martin.h.duke"<[e-mail]>;
>>> "magnus.westerlund"<[e-mail]>;
>>> "david.black"<[e-mail]>; "Gorry
>>> Fairhurst"<[e-mail]>; "wes"<[e-mail]>;
>>> "wanglihe"<[e-mail]>; "tsvwg"<[e-mail]>;
>>>> Subject:  Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
>>>> 
>>>>> On 9. Apr 2020, at 06:46, RFC Errata System <[e-mail]>
>>> 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 <[e-mail]>
>>>>> 
>>>>> 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
>>>>> 
>>>> 
>>>> 
>