Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

Toke Høiland-Jørgensen <toke@toke.dk> Thu, 05 November 2020 11:42 UTC

Return-Path: <toke@toke.dk>
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 75F4A3A177B; Thu, 5 Nov 2020 03:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=toke.dk
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 NzVql12SAt6L; Thu, 5 Nov 2020 03:42:50 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 27FA03A1774; Thu, 5 Nov 2020 03:42:49 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604576566; bh=0Gmb1sTMBVytksvQbDJI7kJR0+b1l9aT4fBMUit2+ZY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=uiLGnOhixSV5vb3SsS03YQM6whTZCJn16UJUHCvCUg95H3B/6UvcjjX3qCrmlnv4q nw5mJDcFr1YhH0mdgTS7mQO2pxLt8R2OyOIydq4c/27UmTBvy+jWbTChZda4yES7au 7T2V/P3XOpUoZPS5pjGzAN4KH5x1MT8ETprnQnRDbIC0ElzbxyrsfMeNUVNXw+KQHh kK4m0OdtervoGFRt3nJvGYDqGq7oW7quoeCXPUJ0Pic85FCBjYdRu/QVhRQPqX4gqg ruwz5EINAQw39E3A/jG6Ui2eCG+RyH1zDwMKotV49KUak7fMN6FxxEiRB21/294+xu SeBRUh3kQ4OPQ==
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
Cc: babel-chairs@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel@ietf.org, draft-ietf-babel-source-specific@ietf.org
In-Reply-To: <160455279459.19842.7370627868131264527@ietfa.amsl.com>
References: <160455279459.19842.7370627868131264527@ietfa.amsl.com>
Date: Thu, 05 Nov 2020 12:42:43 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87pn4st4gc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/Yo3ONmclnMEFljyuAvkYRD1u4DY>
Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)
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: Thu, 05 Nov 2020 11:42:52 -0000

Murray Kucherawy via Datatracker <noreply@ietf.org> writes:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-babel-source-specific-07: No Objection
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> What's an example of when one might deviate from the SHOULD in Section
> 4?

Only thing I can think of is that if someone already implemented a
disambiguation like that suggested in the second bullet, and the
underlying platform then adds native support, one could conceivably
continue using the disambiguation instead of switching to the native
support.

The Linux kernel is an example of this: in ancient times there was no
native support for source-specific routing, but it was possible to use
the generic policy routing mechanism to achieve this. When the native
support was added, it came with a new UAPI, so a routing daemon would
have to change to support it, while the old policy-based way would still
work. Or maybe an implementation wants to support ancient kernels with
the same code and keeps using the policy-routing based way; it would
likely be somewhat painful, but in principle I suppose it could work.

-Toke