Re: [babel] [Babel-users] rather than ripemd160...

Toke Høiland-Jørgensen <toke@toke.dk> Mon, 26 November 2018 20:59 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 18261130DBE for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 12:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AhvoGvQC6289 for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 12:59:53 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE59130DCC for <babel@ietf.org>; Mon, 26 Nov 2018 12:59:48 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1543265983; bh=CpCU0UachM+JM8TG48qe2N/ALw8sywa9lC5bDvmBmlg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HZoKsBpszPC6HP8dzBtmVq0v51jv0VY1imD4VHJPZThB9VFB0NoCXHqb9duZeJH0p xxTT6NWu47nOl9rnZlg+RWyZ8+YUtBeQ5bsRXFtITZj5xDvLkg2ndQebVSaTgW9bCL ahMvyNWYBKMKpcIPlIvbAAK77ntuT9MPYCcorwoTe+i3d1rcGmPo3pENU27qQGfxni bUR0Z51cllSbC4uMcyYvZaXsF1FFfkROIrZizQqnYxKRQ3VA0SHtw7u8TV/9Wh/hAw /JGOiCJK0CrLBKOqkqdl2ENJKT04lMie2wdYRpz9+ixLQLJb+O6WeXLGFGEje3WthQ CNvnnAr1kLyWA==
To: "STARK, BARBARA H" <bs7652@att.com>, Dave Taht <dave.taht@gmail.com>
Cc: Babel at IETF <babel@ietf.org>, babel-users <babel-users@lists.alioth.debian.org>, Juliusz Chroboczek <jch@irif.fr>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Mon, 26 Nov 2018 21:59:41 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87pnurwo5e.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/je7X850LRMGYDKLF8cuKy44IYgA>
Subject: Re: [babel] [Babel-users] rather than ripemd160...
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: Mon, 26 Nov 2018 20:59:56 -0000

"STARK, BARBARA H" <bs7652@att.com> writes:

> FYI. IETF policies re "downrefs" in standards track RFCs is described in
> https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/html/rfc8067).
> In short, it's not prohibited, but careful review is required. 
> Note RFC3967 Section 2 first bullet
>
>    There are a number of circumstances in which an IETF document may
>    need to make a normative reference to a document at a lower maturity
>    level, but such a reference conflicts with Section 4.2.4 of
>    [RFC2026].  For example:
>
>    o  A standards track document may need to refer to a protocol or
>       algorithm developed by an external body but modified, adapted, or
>       profiled by an IETF informational RFC, for example, MD5 [RFC1321]
>       and HMAC [RFC2104].  Note that this does not override the IETF's
>       duty to see that the specification is indeed sufficiently clear to
>       enable creation of interoperable implementations.

Ah, so HMAC itself is already an informational RFC? Great, let's do
blake2, then! :D

-Toke