[babel] Shepherd review of draft-ietf-babel-v4viav6-03

Donald Eastlake <d3e3e3@gmail.com> Wed, 19 May 2021 22:26 UTC

Return-Path: <d3e3e3@gmail.com>
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 258E73A218C; Wed, 19 May 2021 15:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R1ItP5nvqADY; Wed, 19 May 2021 15:26:37 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FA53A218A; Wed, 19 May 2021 15:26:36 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id j30so13552960ila.5; Wed, 19 May 2021 15:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=l+MU1yoycGPK8MAWKYjk7PNsuYnXrRHPNViHbOpChuc=; b=QibMENf9C6NWqMvcxldcNFjBv0bR+3gGtcVm51kcTvB3lKJLgOc1YQ6zbI1aIvGrA4 6ycITmrv9KPRddn6mt0qF9VSVWJHZ9hjiaNELQ7hdg3VPMM4eiik46MOeLXgYgHNzl6K 4fcHv3M1Cq3G/iKu/RHJ0OY495Fx/hJmz02tpKAXzihwCY2h6fx2SL2Ou13CYPjGwrue VQDhFDsTlxDaAmiO/joYR5thwem3sioCFmVDRMVChIY5KY0LwiuRJ2ERlcfFSZnzetDs Sm2u5vjUlTP4gr2qZfIkSUnmkNpihQ2tipwUkLnEONGgvEQymlLm3Pic2JsT10arpjna 0neg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=l+MU1yoycGPK8MAWKYjk7PNsuYnXrRHPNViHbOpChuc=; b=ZbpOBqX4IbLuxsmXLpVQzi+iCWefbrg3HmF2h02y+xZszrkhFv3hbzyMbPMjnxBHc6 QBVdK95j6fNDNsLE5KTbdaP8hJuFsDoJIju3/pO39LX7x1ePiKxjeHhD0LC2RTtcWbnz jjp5+cEPha0+rvl9uE5POTp85P5u59jGbYlGHDGATrdwBKS+yy2Ueu+VXsAgNakjgSfX mKOWaZXHHHn+ED50Xo7eNMoCQtEutRqg9+FnAGv9hiQMIoZYBCdkRvE6E4Wos6kVCa+4 BPq9+eRtlyizchAWal931dN2vR7iXo1/GsK2wJRpfKJt8LlLJjs0U7Fpz7f+aDZMG6z+ BfKA==
X-Gm-Message-State: AOAM533IGmNaVfZF3MR/fqgN7FiDqORNor/zE9FitHKql5PtQXFsRNDW gOoPoeVxBh/uc1yNC0wrpkWpFzGvWpWOZmX5OYoeMeUizMgD2g==
X-Google-Smtp-Source: ABdhPJwf1UxaoItYrRiLbf5o9+jalNStJFmAqp4PsTSkTBcQ0jtoMnJd5FlMVMXGARUnmm8FQ4Qk+VJLYbGGLjS7puA=
X-Received: by 2002:a92:6b05:: with SMTP id g5mr1509483ilc.40.1621463195399; Wed, 19 May 2021 15:26:35 -0700 (PDT)
MIME-Version: 1.0
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 19 May 2021 18:26:24 -0400
Message-ID: <CAF4+nEGXt+x6BsQNuXwL7MMgChEB574=dW77_y71XMoL_J1rBw@mail.gmail.com>
To: Babel at IETF <babel@ietf.org>
Cc: babel-chairs <babel-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c73b8f05c2b65151"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/5HEAHOesxnerhhq9rZcy92hjfwI>
Subject: [babel] Shepherd review of draft-ietf-babel-v4viav6-03
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: Wed, 19 May 2021 22:26:40 -0000

Hi,

I've done a review of this draft as Shepherd. See below:


INTRODUCTION

The introduction is generally quite good but, in the first paragraph, some
wording feels just the slightest bit off.  For example, it appears to
assume that ND or ARP would always be used when the next-hop to link-
layer address mapping might be statically configured in a wired portion
of a network. Here is some suggested text for the author's
consideration:
OLD
   Traditionally, a routing table maps a network prefix of a given
   address family to a next-hop address in the same address family.  The
   sole purpose of this next-hop address is to serve as an input to a
   protocol that will map it to a link-layer address, Neighbour
   Discovery (ND) [RFC4861] in the case of IPv6, Address Resolution
   (ARP) [RFC0826] in the case of IPv4.  Therefore, there is no reason
   why the address family of the next hop address should match that of
   the prefix being announced: an IPv6 next-hop yields a link-layer
   address that is suitable for forwarding both IPv6 or IPv4 traffic.
NEW
   Traditionally, a routing table maps a network prefix in a given
   address family to a next-hop address in the same address family.
   The sole use of this next-hop address is to determine the
   link-layer address of the next-hop node, for example using
   Neighbour Discovery (ND) [RFC4861] in the case of IPv6 or Address
   Resolution (ARP) [RFC0826] in the case of IPv4.  Therefore, the
   address family of this next-hop address need not match that of the
   prefix being announced: an IPv6 next-hop can determine a link-layer
   address that is suitable for forwarding both IPv6 and IPv4 traffic.



IANA CONSIDERATIONS

Globally TDB -> 4
Also:
OLD
   IANA is requested to allocate a value (4 suggested) in the "Babel
   Address Encodings" registry as follows:

                   +=====+===========+=================+
                   | AE  | Name      | Reference       |
                   +=====+===========+=================+
                   | TBD | v4-via-v6 | (this document) |
                   +-----+-----------+-----------------+
NEW
   IANA has assigned the value 4 in the "Babel Address Encodings"
   registry as follows:

                   +=====+===========+=================+
                   | AE  | Name      | Reference       |
                   +=====+===========+=================+
                   |  4  | v4-via-v6 | (this document) |
                   +-----+-----------+-----------------+



REFERENCES

Update reference to RFC 5549 to RFC 8950.



TRIVIA

Section 2, 1st line: It is more common in IETF documents to say
"dual-stack" rather than "double-stack".

anoncing -> announcing

annoucements -> announcements

administatoris -> administrators

next hop -> next-hop   (7 times)

eg. -> e.g.   (twice)

It would be preferable, within the Normative and the Informative
References, that RFCs be listed in numeric order.

I notice this draft generally uses British spelling. I think that's OK
as long as it is consistent.



Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com