IETF Logo Mail Archive

Re: [Roll] Border router failure detection

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 12 May 2021 15:46 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E723A0CAE for <roll@ietfa.amsl.com>; Wed, 12 May 2021 08:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 f-BLM-Ob_1Bo for <roll@ietfa.amsl.com>; Wed, 12 May 2021 08:46:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D7B3A0CA2 for <roll@ietf.org>; Wed, 12 May 2021 08:46:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9012738EA3 for <roll@ietf.org>; Wed, 12 May 2021 11:55:11 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GL9h_KOl3lJF for <roll@ietf.org>; Wed, 12 May 2021 11:55:10 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D2D2D38ED8 for <roll@ietf.org>; Wed, 12 May 2021 11:55:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AACD63D for <roll@ietf.org>; Wed, 12 May 2021 11:46:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl>
References: <CAP+sJUfcEY2DNEQV=duJdN6P8zZn0ccuei+4ra-B6TcLb5z8Kg@mail.gmail.com> <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <CAO0Djp3w4vWCOawQ+eegNTRzb_HRGYH6n=bdEH6iVf5ZO0AGFQ@mail.gmail.com> <f71fe153-c0d1-097e-a72e-49ece97cbd48@mimuw.edu.pl> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <CO1PR11MB4881A5AA0E5C5010FD2BE39ED8749@CO1PR11MB4881.namprd11.prod.outlook.com> <bc174171-4b68-40b2-d532-463709e5bea8@mimuw.edu.pl> <CO1PR11MB4881D0C985582B28AE2DE8BED84E9@CO1PR11MB4881.namprd11.prod.outlook.com> <ab695952-3b11-46ad-f638-622ca770f8e1@mimuw.edu.pl> <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 12 May 2021 11:46:08 -0400
Message-ID: <8421.1620834368@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/N1EMqdH-1q0l_0VWePzyNZ6RIYc>
Subject: Re: [Roll] Border router failure detection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 15:46:22 -0000

Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
    > Hopefully, I have addressed all your previous comments (at least those
    > that I knew how to address). The changes are in the GitHub repo. My
    > question is:

    >     What now?

    > Despite the introductory videos, it is not completely clear to me what
    > the next steps should be.

A few illustrative slides for a virtual interim meeting, and then pester the
WG chairs to adopt it.   I would support adoption, and I prefer that
documents are adopted early.  (not everyone shares this view, see RFC7221 and rfc7221bis)

    > Moreover, before a new version of the draft is produced, if at all, I
    > would like to discuss a few issues so that the draft best matches the
    > group's practices, both technical and nontechnical:

    > 1. best method for enabling/disabling the protocol

Can it use capex?

    > 2. simplicity vs. generality and reusability

I'd need some examples here.

    > 3. authorship of the draft

The WG chairs essentially decide that, but it is unusual for them not to
consult with you.
(Most of the time, it's whomever fails to step back fast enough.)

BTW: to everyone, a bunch of clusters of documents in 6tisch and ANIMA have
     gotten to AUTH48 in the RFC editing process, and this tends to act as a
     Denial of Service on a bunch of people in this WG.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email