Re: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS)

Martin Duke <> Tue, 16 March 2021 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC5E3A0C0D; Tue, 16 Mar 2021 12:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zfQ1Y2g3WAl4; Tue, 16 Mar 2021 12:23:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65FD73A0C0B; Tue, 16 Mar 2021 12:23:51 -0700 (PDT)
Received: by with SMTP id y20so20116260iot.4; Tue, 16 Mar 2021 12:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v9xS5q6mMBX2wx17uMJk6hJEBs9T+9NNtR7+TqrfXDk=; b=geXlc1ZunxDPxOjaehLzNkdBuoU8TC35QTZxtwaugrEWCzyjIkXON8wHOwFRiYbVqM 3obDeQBlXa/y5eSmFD4NSQiv556y25tPpCuPwv72ogRtUcAYjjfgB4JYqGiVXNaNJcXY ZWaeHSTiAUf/YupoWgLw+uEoBJme640S3uPFUwv/KDiufdmWciStFPkuLTe/0XV0loUz X9m2RFhAbrPbiCPkq7+YItq+ubS3BRstrpUWYPujAZrFvH0BttJNfOaAZk3DVaHBZiML nV/S6gxN3iAWzI9iZKtkRRclnCBcbUz7qoD05a6+ECZgBVWN7QTA5VBMqhTNKBYAkm5j eidA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v9xS5q6mMBX2wx17uMJk6hJEBs9T+9NNtR7+TqrfXDk=; b=nBWBCtT1NScCy9O2kUe28qPmbtTmaj0daqOYxxH21L2+LkwTSGQIVIeKKxUjpc53vm 8rb1L2NGVFwmgnRS0TE3PcOyGjwEjYITxR6bfxNt6JkBGY1efbpMW3FqHOD5WhEErsTg ai8Hg0p+ChSXgVdh1bJGnL1EsRAz2L05Qts/kwLcTq/65hufe/H7LnH4UipkK+dINyrV 6Ri3bDOjzELBHOPeV1DStXWt92Bsw+uuWc/b6afFNwu+olElsmUcvgvHFB7dv6mlRmqv 9Y1GwHtJHkOkmP72/8hfhUmp1RhBxNpgqRUL5jZab8QLMfKqs8XsK3rG36iyk5+5HJKN y+1Q==
X-Gm-Message-State: AOAM532hfzfT/u1uGY2ldYIvD/3M9rAEQI9UuWXCQF5phOAtap7hlIq8 Cu2Eob7Sm6lYw+2wm7ZZp3ltNmiwvu2zFi8LNxY=
X-Google-Smtp-Source: ABdhPJxgNpKyXqrgQFNJESEjM690umboimAf9wEbJ0F4BaTbZ1cGK94l1wFyBN0plQ07humAYKx5yRf/f9Za9Zk/Oeg=
X-Received: by 2002:a05:6602:82:: with SMTP id h2mr4751404iob.20.1615922630011; Tue, 16 Mar 2021 12:23:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <028d01d71a97$5e13f8b0$1a3bea10$>
In-Reply-To: <028d01d71a97$5e13f8b0$1a3bea10$>
From: Martin Duke <>
Date: Tue, 16 Mar 2021 12:23:39 -0700
Message-ID: <>
To: Adrian Farrel <>
Cc: The IESG <>,,,, Susan Hares <>, Jie Dong <>, Alvaro Retana <>
Content-Type: multipart/alternative; boundary="00000000000058b06505bdac4e86"
Archived-At: <>
Subject: Re: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Mar 2021 19:23:54 -0000

I removed the DISCUSS because I don't think this is unimplementable, etc.
The WG just took a very circuitous route to redefine a concept that largely
already exists in 8126.

On Tue, Mar 16, 2021 at 12:05 PM Adrian Farrel <> wrote:

> You are correct that early allocation would meet this requirement,
> however, the WG said that it found the early allocation procedure annoying
> because of the "maturity" requirement, and because of the need to renew
> assignments. The WG wanted to make a one-shot assignment.

To me this seems like a circumvention of the provisional assignment
process. You've saved yourselves this process but added an expert review
step, and should it fail, a clunky deprecation mechanism.

> You are also correct that the addition of the DE guidance strengthens
> Expert Review towards Specification Required, but it doesn't quite get
> there. A lot depends on whether an Internet-Draft is considered to be a
> stable reference. The working group was aware that opinions vary on this
> point and did not want to get into that debate. It seemed pragmatic to use
> Expert Review and set the exact requirements in the DE guidance.

As I said, this is beyond Specification required, as it requires (well,
recommends) the document to be in the IETF stream. This is more like the
"IETF Review" policy from 8126, modulo how much weight you're putting on
the SHOULD. If there are good reasons that's a SHOULD instead of a MUST, I
guess that's a motivation for the path you've taken.

> And, before anyone asks 😉, yes, we could have included explanation text
> in the I-D saying why we have this approach. But, AFAICS, no other document
> has ever included explanation for the choice of assignment policy. Simply,
> this is the policy the WG would like to see applied to the registry.
> Cheers,
> Adrian

I agree that including text to this effect is abnormal.