Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05

Michael Tuexen <tuexen@fh-muenster.de> Mon, 22 March 2021 09:52 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39DC3A0E04; Mon, 22 Mar 2021 02:52:56 -0700 (PDT)
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 0tBmuBlw-_7Z; Mon, 22 Mar 2021 02:52:52 -0700 (PDT)
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 195F43A0E0A; Mon, 22 Mar 2021 02:52:51 -0700 (PDT)
Received: from mbp.fritz.box (ip4d16007f.dynamic.kabel-deutschland.de [77.22.0.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 61F0176FB57FF; Mon, 22 Mar 2021 10:52:46 +0100 (CET)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <AC50FA72-FDFB-495D-92BC-AC29581E1644@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_72226806-05DC-431C-9B20-FD460D70983D"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 22 Mar 2021 10:52:45 +0100
In-Reply-To: <9482_1616405491_605863F3_9482_55_1_787AE7BB302AE849A7480A190F8B93303535925D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-rfc8782-bis.all@ietf.org" <draft-ietf-dots-rfc8782-bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
To: mohamed.boucadair@orange.com
References: <161636957782.14687.3973826310014534947@ietfa.amsl.com> <19201_1616395378_60583C72_19201_281_1_787AE7BB302AE849A7480A190F8B9330353590AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DF63CB57-1AC4-4FB6-9F62-7B6DB3541496@fh-muenster.de> <9482_1616405491_605863F3_9482_55_1_787AE7BB302AE849A7480A190F8B93303535925D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/-p5QfYVqctT7ZfvKYdYneH8Ptqg>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2021 09:52:57 -0000

> On 22. Mar 2021, at 10:31, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : tuexen@fh-muenster.de [mailto:tuexen@fh-muenster.de]
>> Envoyé : lundi 22 mars 2021 10:04
>> À : BOUCADAIR Mohamed TGI/OLN
>> <mohamed.boucadair@orange.com>
>> Cc : tsv-art@ietf.org; dots@ietf.org; draft-ietf-dots-rfc8782-
>> bis.all@ietf.org; last-call@ietf.org
>> Objet : Re: Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
>> 
>>> On 22. Mar 2021, at 07:42, <mohamed.boucadair@orange.com>
>> <mohamed.boucadair@orange.com> wrote:
>>> 
>>> 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.
>>> 
>>> ==
>>>        DISCUSSION:
>>>             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:
>>> 
>>> OLD:
>>>  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].
>>> 
>>> NEW:
>>>  assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3
>> of [RFC1122]).
>> Hi Med,
>> 
>> let me try to get my point clear:
>> 
>> You can use Section 3.3.3 of [RFC1122] to motivate that the sender
>> should
>> not send datagram larger than 576, since there is no guarantee that the
>> receiver has resources to reassemble and process it. But RFC 1122
>> makes
>> no statement about the path. 
> 
> [Med] There is this text in RFC1122: 
> 
>              Since nearly all networks in the Internet currently
>              support an MTU of 576 or greater, we strongly recommend
>              the use of 576 for datagrams sent to non-local networks.
OK. Then I' fine with your proposed text.
Please note that this is a statement from 1989. It is fine if you can live with that number, I would
guess that such a number is larger today (at least in the context of WebRTC a number in the order of
1200 bytes was used).

Best regards
Michael
> 
> As far as I know there is no safe value
>> for
>> a PMTU you can derive from a specification.
>> 
> 
> [Med] I agree with you. Things are more clear for IPv6.
> 
>> 
>> So maybe:
>> NEW:
>>  assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of
>> [RFC1122]
>>  for support at the receiver).
>> 
>> Best regards
>> Michael
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Michael Tüxen via Datatracker [mailto:noreply@ietf.org]
>>>> Envoyé : lundi 22 mars 2021 00:33
>>>> À : tsv-art@ietf.org
>>>> Cc : dots@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org; last-
>>>> call@ietf.org
>>>> 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 tsv-art@ietf.org 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.
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>