Re: [Detnet] Tsvart last call review of draft-ietf-detnet-bounded-latency-08

Mohammadpour Ehsan <> Wed, 16 February 2022 09:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17E133A0D1D for <>; Wed, 16 Feb 2022 01:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ecdC5DasF4dB for <>; Wed, 16 Feb 2022 01:42:37 -0800 (PST)
Received: from ( [IPv6:2001:620:618:1e0:1:80b2:e058:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B04353A08D6 for <>; Wed, 16 Feb 2022 01:42:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=epfl; t=1645004154; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; bh=Lsaav1rIHLSzkirGpu0qAQFbpf63/8rEGfNybhfudc0=; b=TQ//PI0UHFmpKQDwP1f9qBIso6rKBTUnhBcOX02jPWea9t1BQcucdile60DyuSi3a 4KjkdOSCXVvvZ24ZlbooJFA2vXQHhGGzm58e1vy1cLuhmjU6Es/7fv/iCHTXbp1nA tgJ5NMaf/HGV0PanYguD0h/20Ar7bXVjD90xsXKlI=
Received: (qmail 4176 invoked by uid 107); 16 Feb 2022 09:35:54 -0000
Received: from (HELO ( (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) by (AngelmatoPhylax SMTP proxy) with ESMTPS; Wed, 16 Feb 2022 10:35:54 +0100
X-EPFL-Auth: cp5fW5HdBZ6/Zt44jJT4nk+X8Pb7MdFYqMwt2GjyUQ8vGJG4Ojw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Wed, 16 Feb 2022 10:35:54 +0100
Received: from ([fe80::ddaf:e0cc:a2d6:4aaf]) by ([fe80::ddaf:e0cc:a2d6:4aaf%3]) with mapi id 15.01.2375.018; Wed, 16 Feb 2022 10:35:54 +0100
From: Mohammadpour Ehsan <>
To: Yoshifumi Nishida <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-detnet-bounded-latency-08
Thread-Index: AQHYG0zSM/LsRF3NikC8JDtg0lC8rayV6dGA
Date: Wed, 16 Feb 2022 09:35:54 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, fr-CH
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_29CE39E748A7439EA426AC448029EF87epflch_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Detnet] Tsvart last call review of draft-ietf-detnet-bounded-latency-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Feb 2022 09:42:41 -0000

Dear Yoshi,

Thanks for your feedback. The document covers the case when packet reordering occurs within a DetNet node. In the new version, we made it clear in the introduction. You can find the new version of the draft in:

as well as the difference between the new version and the previous version in:


Ehsan Mohammadpour
PhD candidate at Swiss Federal Institute of Technology (EPFL)
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland

On 6 Feb 2022, at 12:29, Yoshifumi Nishida via Datatracker <<>> wrote:

Reviewer: Yoshifumi Nishida
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.

I think the draft is well written and informative. I haven't found any
transport related issues in the document. I think the draft is ready for
publication. One minor comment I have in the draft is if we can safely assume
there is no packet reorder in this architecture. I think it would be better to
mention it in the document.