Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

Juliusz Chroboczek <jch@irif.fr> Fri, 18 October 2019 16:46 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFA812002E; Fri, 18 Oct 2019 09:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 fitr4T745rkN; Fri, 18 Oct 2019 09:46:16 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7E212000F; Fri, 18 Oct 2019 09:46:15 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x9IGkA0I019257; Fri, 18 Oct 2019 18:46:10 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A9605C896F; Fri, 18 Oct 2019 18:46:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id lsUAFIIWVlpw; Fri, 18 Oct 2019 18:46:12 +0200 (CEST)
Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0F7C3C896D; Fri, 18 Oct 2019 18:46:11 +0200 (CEST)
Date: Fri, 18 Oct 2019 18:46:11 +0200
Message-ID: <87imomknn0.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, babel@ietf.org, The IESG <iesg@ietf.org>
In-Reply-To: <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net>
References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 18 Oct 2019 18:46:10 +0200 (CEST)
X-Miltered: at korolev with ID 5DA9EC52.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5DA9EC52.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5DA9EC52.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/odqaKbStmWSBdDMBl12-x6z6P2w>
Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 18 Oct 2019 16:46:19 -0000

Dear Mirja,

> 1) Let's move appendix B into the body of the document. I think these
> are important information for an implementer and therefore it needs more
> attention.

I am sorry, but I disagree.  The original document that I submitted for
IETF review back in 2009 had the structure that you suggest, but the
reviewer (Joel Halpern) convinced me to a adopt the following structure:

  - the body of the document describes the main algorithm, the parts that
    are required to enforce the strong guarantees that the protocol makes
    about lack of loops and forward progress;
  - the appendices describe algorithms that have been shown to be useful
    over some link layers but that might need to be tweaked when Babel is
    run over new, exciting link layers.

Since Joel did a good job convincing me, it will take some work to
convince me otherwise.

> 2) Maybe you can add something like: [...]  I’m sure you have a better
> wording. My intention is simply to add another warning, to think
> carefully instead of just pick some default.

I don't necessarily agree, but I've done as you request.

>>> Thanks. I was also hoping that you could make any recommendation on how
>>> to implement that e.g. a fixed delay of a certain (default) value or
>>> based on some other knowledge. [...]

>> You do realise it's a very high bar you're setting?

[...]

> I wasn’t looking for a tutorial for pacing but rather a reference to
> add. E.g. just naming different approaches for how to implement pacing
> and provide a reference would be a good thing I think. However, I will
> not block on this one thing. Your choice.

I am not aware of any good reference on packet pacing that covers IEEE
802.11 multicast (an important usecase for Babel).  After checking some
papers and scratching my head for a long time, I've just added another
sentence to Section 3.1; I'm afraid I'm not competent to do anything more.

> I just wondering why you don’t call them default value rather then
> examples. I think specifying default value normatively would be more
> clear and is what we usually do in specs. However, I think in this case
> it will not make a huge practical difference.

Great, let's agree that we're not in full agreement, then.

-- Juliusz