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

Barry Leiba <barryleiba@computer.org> Mon, 25 January 2021 18:34 UTC

Return-Path: <barryleiba@gmail.com>
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 58B173A1727 for <rtcweb@ietfa.amsl.com>; Mon, 25 Jan 2021 10:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level:
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 3tf1WaNTrhz7 for <rtcweb@ietfa.amsl.com>; Mon, 25 Jan 2021 10:34:02 -0800 (PST)
Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC0C3A172C for <rtcweb@ietf.org>; Mon, 25 Jan 2021 10:34:02 -0800 (PST)
Received: by mail-lf1-f41.google.com with SMTP id a8so19249268lfi.8 for <rtcweb@ietf.org>; Mon, 25 Jan 2021 10:34:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uUZi+KkQZxGM2AHfbCAwcqw8E2oyiz8dqThZmF5sThY=; b=EoU4iic6t488wwW01GvNKqxRzSz1B7LSgACxHeq4G057JdMYlVrMfDENGr9FyQFX7g 8K2bpXhc9f7D4u/q0BvTUSAO23hodoa5muUjgCq2GjB90MqcKN7WpfeENNJ7mjSq5Gez WnNEYUmfXhceA8TZEbmYg7Y/U1/SqH79ePmwuo8HK7PRQAvp4+x9IDkfom7yOznZ5QbC qxILmWwmm+UK6HUtAZlxxjajcBrVgEoa4gexAOBOekz7FTEL40PeanJBj1qcOlF8UXFJ tkLzwRFaBzjh/Jv26XFcgrXHR5J7etcSIEcWQ2ebN5Z1VSwnbdxk0KBOaEAFv+sEZpyb gcbw==
X-Gm-Message-State: AOAM530wqgd/nxT+YPrNc5SLIzBHe2wJ826XvePZGOj2T+u9sLwCTX9X LMkF0i3LZ+BSH1Vp6fioZIvgwgrQOsVuAeUiMv0=
X-Google-Smtp-Source: ABdhPJxJxx9eW1l1sU4KgLS9cqVz+wmyaJSPslj9OC3XAnKEIjebgY9UrAgUP/1WqydjozKtjhDJ8iqT/bmIdiXakjY=
X-Received: by 2002:ac2:592a:: with SMTP id v10mr830241lfi.123.1611599640076; Mon, 25 Jan 2021 10:34:00 -0800 (PST)
MIME-Version: 1.0
References: <20210125092848.3AF95F40764@rfc-editor.org> <CA+9kkMBJTN-U0WNdSRJ6PdOPBHwayfWxUGebThr+iHOM_QmYqQ@mail.gmail.com> <CAFaRDoL1nCwVE=3g-O-CV-ZjVT6Ggb9rP8JX3rmMcnaLN62jPw@mail.gmail.com>
In-Reply-To: <CAFaRDoL1nCwVE=3g-O-CV-ZjVT6Ggb9rP8JX3rmMcnaLN62jPw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 25 Jan 2021 13:33:48 -0500
Message-ID: <CALaySJLX2eHrNogJ_f7FFRjyHLEasJa02-dbtgOwSmON_s2H9g@mail.gmail.com>
To: Victor Boivie <boivie@google.com>
Cc: 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>, Michael Tuexen <tuexen@fh-muenster.de>, "Murray S. Kucherawy" <superuser@gmail.com>, sean+ietf@sn3rd.com, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/lJEhq_KVGLVZEdJAQ9c-jBXJPrw>
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:34:06 -0000

>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 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