Re: [rtcweb] [Technical Errata Reported] RFC8832 (6411)

Michael Tuexen <tuexen@fh-muenster.de> Mon, 25 January 2021 18:38 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D5A3A1734 for <rtcweb@ietfa.amsl.com>; Mon, 25 Jan 2021 10:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.42
X-Spam-Level:
X-Spam-Status: No, score=0.42 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 HCiUYQwJnfyV for <rtcweb@ietfa.amsl.com>; Mon, 25 Jan 2021 10:38:23 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8673A1731 for <rtcweb@ietf.org>; Mon, 25 Jan 2021 10:38:22 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:8cdb:3c2b:1f77:6217] (unknown [IPv6:2a02:8109:1140:c3d:8cdb:3c2b:1f77:6217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AB85A7220C6CE; Mon, 25 Jan 2021 19:38:18 +0100 (CET)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <72719DA8-11DC-4B51-822A-49F643986389@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_2B95244D-A8F2-4A7F-BE81-AFA8F7B1E6C3"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Mon, 25 Jan 2021 19:38:18 +0100
In-Reply-To: <CALaySJLX2eHrNogJ_f7FFRjyHLEasJa02-dbtgOwSmON_s2H9g@mail.gmail.com>
Cc: Victor Boivie <boivie@google.com>, Ted Hardie <ted.ietf@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Randell Jesup <randell-ietf@jesup.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>, "Murray S. Kucherawy" <superuser@gmail.com>, sean+ietf@sn3rd.com, RTCWeb IETF <rtcweb@ietf.org>
To: Barry Leiba <barryleiba@computer.org>
References: <20210125092848.3AF95F40764@rfc-editor.org> <CA+9kkMBJTN-U0WNdSRJ6PdOPBHwayfWxUGebThr+iHOM_QmYqQ@mail.gmail.com> <CAFaRDoL1nCwVE=3g-O-CV-ZjVT6Ggb9rP8JX3rmMcnaLN62jPw@mail.gmail.com> <CALaySJLX2eHrNogJ_f7FFRjyHLEasJa02-dbtgOwSmON_s2H9g@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/3G2w2CTkd2sZxleYQNiuNUigUMU>
Subject: Re: [rtcweb] [Technical Errata Reported] RFC8832 (6411)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 18:38:27 -0000

> On 25. Jan 2021, at 19:33, Barry Leiba <barryleiba@computer.org> wrote:
> 
> From the point of view of "errata", though, the question is whether
> this was an omission that would have been fixed if it had been caught
> at the time of publication... or something that was not put in because
It was an omission.

Best regards
Michael
> it was considered to be covered elsewhere, so not an "error" in the
> RFC.
> 
> It seems the latter, not the former.
> 
> Barry
> 
> On Mon, Jan 25, 2021 at 1:21 PM Victor Boivie <boivie@google.com> wrote:
>> 
>> While I absolutely accept that rationale, Data Channel Establishment Protocol is layered on top of SCTP, and is not an SCTP extension (where I would definitely agree with what you're saying).
>> 
>> While I can't see what the future brings, I could envision an evolution of RFC8832 being layered on top of e.g. QUIC or SRT, would the WebRTC project decide to change the underlying protocol from SCTP to something else in the future. That would be a separate RFC, though.
>> 
>> Thanks and best regards,
>> Victor
>> 
>> On Mon, Jan 25, 2021 at 6:40 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>>> 
>>> Since the Data Channel Establishment Protocol depends on SCTP, which requires Network Byte Order (RFC 4960, Section 3), I do not believe that this erratum is needed.  I recommend it be rejected.
>>> 
>>> Just my personal opinion,
>>> 
>>> regards,
>>> 
>>> Ted
>>> 
>>> On Mon, Jan 25, 2021 at 1:28 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>>> 
>>>> The following errata report has been submitted for RFC8832,
>>>> "WebRTC Data Channel Establishment Protocol".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid6411
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Victor Boivie <boivie@google.com>
>>>> 
>>>> Section: 5
>>>> 
>>>> Original Text
>>>> -------------
>>>> 5.  Message Formats
>>>> 
>>>>   Every Data Channel Establishment Protocol message starts with a one
>>>>   byte field called "Message Type" which indicates the type of the
>>>>   message.  The corresponding values are managed by IANA (see
>>>>   Section 8.2.1).
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> 5.  Message Formats
>>>> 
>>>>   Every Data Channel Establishment Protocol message starts with a one
>>>>   byte field called "Message Type" which indicates the type of the
>>>>   message.  The corresponding values are managed by IANA (see
>>>>   Section 8.2.1).
>>>> 
>>>>   All integer fields in an Data Channel Establishment Protocol message
>>>>   MUST be transmitted in network byte order, unless otherwise stated.
>>>> 
>>>> Notes
>>>> -----
>>>> The byte order of integer fields in the protocol messages is not defined.
>>>> 
>>>> 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.
>>>> 
>>>> --------------------------------------
>>>> RFC8832 (draft-ietf-rtcweb-data-protocol-09)
>>>> --------------------------------------
>>>> Title               : WebRTC Data Channel Establishment Protocol
>>>> Publication Date    : January 2021
>>>> Author(s)           : R. Jesup, S. Loreto, M. Tüxen
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Real-Time Communication in WEB-browsers
>>>> Area                : Applications and Real-Time
>>>> Stream              : IETF
>>>> Verifying Party     : IESG