Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05 Mon, 22 March 2021 06:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5248D3A1514; Sun, 21 Mar 2021 23:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tiIwuRSjVJNE; Sun, 21 Mar 2021 23:43:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0EDE3A1516; Sun, 21 Mar 2021 23:43:00 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) by (ESMTP service) with ESMTP id 4F3lLV6wk8z4wc2; Mon, 22 Mar 2021 07:42:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1616395379; bh=eMXQcPk2S6TZVc3lpyEBMea26NI191P0yHlXGS350RQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YqEDCo7FY5E8OZBOtgp5BsMGxjeCi5PVpUnKxvxWQ+oJlOtJUohw89j5VLqGXaHy4 wzuGRavL3JvfZIJMo4JV7dGlzB77nW1Xu/9nIWgBFmhZnTbz6d2eBRqIzbiE8LADQi qPaF1y0cKfBjiphGDwatJx/h/xevflkYEIyuEhwwz6AOTPxUSK6JVFIcOL58ninWEs 2kiWFhSeemGGgyJWEq6rrI4ZkD2eQZPbEWbTey//DnmjscP7PRgI1ek90gMEVZmL5W Qqz35Xp/NvSdLCCi4KsbZDgiClkn4NRsuavJu8K11PwqEXmCl5xwmW6u/HE0frybiL o6RP7befDKHkQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by (ESMTP service) with ESMTP id 4F3lLV67S1zyQ6; Mon, 22 Mar 2021 07:42:58 +0100 (CET)
From: <>
To: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
Thread-Index: AQHXHqqIY6JZ5pCCZkSei8TGS54JqqqPho2A
Date: Mon, 22 Mar 2021 06:42:58 +0000
Message-ID: <19201_1616395378_60583C72_19201_281_1_787AE7BB302AE849A7480A190F8B9330353590AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Mar 2021 06:43:06 -0000

Hi Michael, 

Thank you for the review.

The motivation was used as it was the key element in the discussion in Section 3.3.3 of RFC1122, but you made a fair comment.

              Picking the correct datagram size to use when sending data
              is a complex topic [IP:9].

              (a)  In general, no host is required to accept an IP
                   datagram larger than 576 bytes (including header and
                   data), so a host must not send a larger datagram
                   without explicit knowledge or prior arrangement with
                   the destination host.

We can update the text as follows: 

   assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host
   must be capable of receiving a packet whose length is equal to 576
   bytes as discussed in [RFC0791] and [RFC1122].

   assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122]).


> -----Message d'origine-----
> De : Michael Tüxen via Datatracker []
> Envoyé : lundi 22 mars 2021 00:33
> À :
> Cc :;; last-
> Objet : Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
> Reviewer: Michael Tüxen
> Review result: Ready with Nits
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are copied
> to the document's authors and WG to allow them to address any
> issues raised and also to the IETF discussion list for information.
> When done at the time of IETF Last Call, the authors should consider
> this review as part of the last-call comments they receive. Please
> always CC if you reply to or forward this review.
> >From a transport perspective, there is one minor issue:
> Section 7.3 provides a motivation for using a path MTU for IPv4 of 576
> bytes.
> The motivation refers to the requirement that a receiver is capable of
> receiving IPv4 packets of that size, however they can be received
> fragmented.
> While it is acceptable to use 576 bytes as the minimum PMTU, the
> motivation does not hold.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.