[babel] Éric Vyncke's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 14 February 2024 08:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B69C14F5F9; Wed, 14 Feb 2024 00:22:21 -0800 (PST)
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>
Cc: draft-ietf-babel-rtt-extension@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com, antoine@aft.network, pascal.thubert@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <170789894193.50078.8678912601753465630@ietfa.amsl.com>
Date: Wed, 14 Feb 2024 00:22:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/4jq-6zRjfSdKRgCuzI1G8j5NT3k>
Subject: [babel] Éric Vyncke's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 08:22:22 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-rtt-extension-05: Discuss

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-babel-rtt-extension/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-babel-rtt-extension-05

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (super easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Donald Eastlake for the shepherd's write-up including the WG
consensus *and* the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-05-intdir-telechat-fressancourt-2024-02-12/
(and I have read the interaction with Juliusz)

Please note that Pascal Thubert is the IoT directorate reviewer (at my request)
and you may want to consider this iot-dir review as well when it will be
available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/reviewrequest/18839/

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract

Please address the id-nits detected issue:

```
  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC8967, but the
     abstract doesn't seem to mention this, which it should.
```


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

# COMMENTS (non-blocking)

## Generic question

It seems that the assumption is that the transmission delay is symmetric. Is it
always the case ? I.e., could it be possible that A->B is faster than B->A ?
E.g., the good old ADSL has different serialisation time and the same may also
happy with Wi-Fi.

Does babel also handle average transmission queue length/delay as input ?

## Section 3.1

Is the Receive timestamp also modulo 2**32 ? Perhaps worth specifying.

## Section 3.2

Like noted by other ADs, please expand 'IHU' at first use.

## Section 3.4

While I like the useful implementation note, should there be a reference to
CLOCK_MONOTONIC ?

## Section 4

As noted by other ADs, I also find strange to use the word "experimental" in a
standard track document. Suggest rewriting this part using other terms.

## Section 6.2

About the discussion when the Length field is larger than 8, I would strongly
suggest to also ignore the TLV as the timestamps length cannot be asserted,
i.e., the first octet of receive timestamp could actually be part of the origin
timestamp.

# NITS (non-blocking / cosmetic)

## µs or microsecond

Suggest to use either "µs" or "microsecond" but not both forms in the same
document.