[tsvwg] Éric Vyncke's No Objection on draft-ietf-tsvwg-sctp-zero-checksum-10: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Tue, 11 June 2024 14:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8DBC18DBB9; Tue, 11 Jun 2024 07:43:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171811701841.18802.9047021240907203523@ietfa.amsl.com>
Date: Tue, 11 Jun 2024 07:43:38 -0700
Message-ID-Hash: 2GDWQJEN2J5G2U57CXETYCPGLPAH47SJ
X-Message-ID-Hash: 2GDWQJEN2J5G2U57CXETYCPGLPAH47SJ
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-tsvwg-sctp-zero-checksum@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Éric Vyncke <evyncke@cisco.com>
Subject: [tsvwg] Éric Vyncke's No Objection on draft-ietf-tsvwg-sctp-zero-checksum-10: (with COMMENT)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DqyKT8Z6BMdElXXu271ylx2WBmw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Éric Vyncke has entered the following ballot position for
draft-ietf-tsvwg-sctp-zero-checksum-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-zero-checksum/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-sctp-zero-checksum-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Marten Seemann for the shepherd's detailed write-up including
the WG consensus _and_ the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

Is CRC32c really a checksum ? I guess it includes a polynomial function, i.e.,
a little more than a simple checksum. I note that SCTP uses a field named
'checksum' but using "CRC32c integrity check" would probably be more suitable.

s/use SCTP encapsulated in DTLS/use SCTP over DTLS/ ? I.e., "encapsulate" is
more often used when one payload is completely contained in another payload and
especially applicable to "tunnels". Mostly a nit though.

## Section 3

```
When using such alternate error detection methods, the SCTP common header
containing the 32-bit checksum field might or might not be visible to
middleboxes on the paths between the two endpoints. ```

While I fail to understand the sentence above, I really wonder why a
"middlebox" (where is such a term defined ?) should care about the checksum
field is visible or not ?

## Section 4

`All transported integer numbers are in "network byte order" a.k.a., Big
Endian.` isn't it implicit in all IETF I-Ds ? Again mostly a nit.

## Section 6

`IANA is requested to assign the Error Detection Method Identifier of 1 for
this method.` should this rather appear in the IANA considerations ? Or at
least having a not to the RFC editor to replace this paragraph by "IANA has
assigned 1 ....".