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

mohamed.boucadair@orange.com Mon, 22 March 2021 11:58 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3163A129E; Mon, 22 Mar 2021 04:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 9BKXSHqtCj_n; Mon, 22 Mar 2021 04:58:25 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 CEA9F3A129D; Mon, 22 Mar 2021 04:58:24 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4F3tLM6LK3z2xld; Mon, 22 Mar 2021 12:58:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1616414299; bh=KpeIIUuPo8uQ/bDnqo4OsFoYQ9vkgh9opW5A0vQcIXs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=X1WcP7BleZLuUXqhkdC0SwXRUsJwZ4dovxqCLDZVic3lD7x2Gof8CFdwSCPNayv0q LRDdr5AKrjvsnvopYFfQX0qm14yW9erbip0W1gW6MobR8ugxdG75NqY3E9bUHE8MwX 8VzcThzRBjvj5Dry9aHFqHYoSbrtoa+ro99EcYh3bxppA0TZggqt0Y7nYm/4UFyQjf 7x2rM2QbdwvsZiF5DeeXE6tZlyM1CKgRE3V/PZkB2RZRGmRK7Q8ns1Q500H5E59WUj YLk8KbnQIOgTt2fv93wQfGyPEIlClk+RIX2XQSD151Su47B9wc6y8sxAN3bUkGIq7f HGzL5yZtIWCbg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4F3tLM5302z1xpK; Mon, 22 Mar 2021 12:58:19 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Michael Tuexen <tuexen@fh-muenster.de>
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>
Thread-Topic: Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
Thread-Index: AQHXHwEeXdhkH7ZT7EWjyQsb3F4e06qP5ZHw
Date: Mon, 22 Mar 2021 11:58:18 +0000
Message-ID: <23668_1616414299_6058865B_23668_496_1_787AE7BB302AE849A7480A190F8B9330353594B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <AC50FA72-FDFB-495D-92BC-AC29581E1644@fh-muenster.de>
In-Reply-To: <AC50FA72-FDFB-495D-92BC-AC29581E1644@fh-muenster.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/lMilg7nnVSrwT1F7TIuQWsTxN3Y>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-rfc8782-bis-05
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2021 11:58:30 -0000

Re-

Thanks, Michael. 

The proposed change is now implemented in our local copy. It can be tracked at https://tinyurl.com/8782bis-latest.

Cheers,
Med

> -----Message d'origine-----
> De : Michael Tuexen [mailto:tuexen@fh-muenster.de]
> Envoyé : lundi 22 mars 2021 10:53
> À : 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 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.