Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 25 March 2021 13:38 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272893A2171; Thu, 25 Mar 2021 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 svt9X2b5DBHL; Thu, 25 Mar 2021 06:38:40 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 2A7EF3A2170; Thu, 25 Mar 2021 06:38:39 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id k10so3027537ejg.0; Thu, 25 Mar 2021 06:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=OobDHuSY2HrqcQ0T2UY0EhfKz2vFbbCtlPPVemhPTlQ=; b=je2gsoA6tUrgnBuGQejjeD049pCMVBZqnKRDsdf+hXx1fHBLiS7EPPOgGf8sz/TDWq dEvNjF9aTKcFOKfnebA+rwXiu7T+CcLsCHZkvOGBMNmQS/5wPdlUsLT+vFB1DoGuZPyf x1zhhF+qHcLwahzMIgVc6dFrmtYjYzEJXUKg8gu0CMXJFdszRxzoE55xqz4o8aSPFZvw yD07Epc3QpUWcGixmse+hyTsBYouBGK/oz5BkPXbgSDXd90NPfSOxS0YCf1nVCDRsTUa 9SpZz193AGWtCguoxkMFk5jyc+ScrtYWRwwmo7cinj50u6SIjQMMntAPURSmJ+6a08+C soDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=OobDHuSY2HrqcQ0T2UY0EhfKz2vFbbCtlPPVemhPTlQ=; b=ZLkWXzF3B3l/7z37TEgdS6N5l434bNf9xrNkgGqinavUXJcBny17oYuKsw0xDo2SQ8 vdFkwbbZKKTY2wZ2zcyIYQJ9oMKi9EjhxhLYzZoNtCLKtbYsylWnopvHBl0pMMYcSwoa fe2H/HSpv6vq9jTcSS09jHrzK5ZBWB2AvWJhB/+sX9qdVM8vkFhE2POLBq4B88aSam3u d+Ki5Ut0kLIv86umkaHCB5AZtUF1cB+XMXH71XqPsoiwae7S7sftLJ/EtwK+dAJwWPd+ hXocXHgp/pC/bbEyBdU/RCi2mWkkCsjvm/NUOk85ZIFKL/u8mhX8r87gp3H9LBWb1Utr Rm1Q==
X-Gm-Message-State: AOAM530+yH5QTiqdnNKwEgd6WwqF3a1xGCjtkjjP3O3FXcgtNc/mYzVQ lbkfRtuj3minvzskeWjKAwL1F4dcokA3KC2xQScKW56A
X-Google-Smtp-Source: ABdhPJyn1cmCODInJIc95vK4PgdzSKaXCW/8AoLVn9EyA45xkvpvtavSjK42HTBmtiv/CfsOgYWVC9wyeCLEFUOn5gQ=
X-Received: by 2002:a17:906:d554:: with SMTP id cr20mr9668906ejc.61.1616679516066; Thu, 25 Mar 2021 06:38:36 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Mar 2021 08:38:35 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MN2PR11MB4366DC7D110C598A43514F78B5629@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <161661295805.2977.9359905854244102147@ietfa.amsl.com> <0dea01d720e5$57d670f0$078352d0$@olddog.co.uk> <A9CD655E-9EA9-4259-977F-460B8990DA5D@eggert.org> <MW3PR11MB4570A7F7DB70BEF35ACD716DC1629@MW3PR11MB4570.namprd11.prod.outlook.com> <MN2PR11MB4366DC7D110C598A43514F78B5629@MN2PR11MB4366.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Thu, 25 Mar 2021 08:38:35 -0500
Message-ID: <CAMMESsyO7k-zdvQwDZMz4CwgrXZRm9q8Vx-drsS2XuGC2Ay8Pw@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>
Cc: Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-bgp-ls-registry@ietf.org" <draft-ietf-idr-bgp-ls-registry@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "idr@ietf.org" <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CtZmlcM90hdGjJUpBJNsGXoRTBM>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 13:38:41 -0000

On March 25, 2021 at 8:52:00 AM, Rob Wilton wrote:

Hi!

We can talk more at the Telechat, but here are more thoughts.

In the end, the WG wants better oversight and more flexibility.

> This document works around an issue rather than fixing it at source. I.e., is
> every WG going to have these registry change documents to change their
> registries to Expert Review to make early allocation easier?

I know that the process of early allocation keeps coming up.  But it
is more than that.  rfc7120 says this in §2 (Conditions for Early
Allocation):

   ...requests for early assignment of code points from a "Specification
   Required" registry are allowed if the specification will be published as
   an RFC.

This point tightens the consideration around when, and to what, should
an early allocation be made, as well as the source of the request.

As mentioned, idr has a strict 2-implementation policy: work won't
progress unless there are two implementations, implementations need
codepoints, codepoints can be allocated "if the specification will be
published as an RFC", but we need implementations to make sure the
document will advance, which require codepoints, etc..

Also, given the use of BGP-LS, which carries information towards a
"consumer" (rfc7752) (aka controller), the potential sources of
information desired increases to include potential work from outside
the IETF -- work that may never be published as an RFC, but which
might require an early allocation.  For example, a significant amount
of BGP-LS extensions come from the in-house development of ISIS/OSPF,
but ISIS is already actively being used by IEEE in SPB (802.1aq) --
the IETF version of L2 routing is trill (we already closed the WG) --
with deployed implementations of both, it is possible that requests
will be made...but rfc7120 doesn't allow for early allocation (unless
"the specification will be published as an RFC"), regardless of
whether the process can be made easier or not (unless that requirement
is removed, of course).

I believe that the implementation requirement + allocation flexibility
is not common to all WGs.  Solving "the problem" for idr (BGP-LS
specifically) may not end up working for everyone else.  One size
doesn't always have to fit all.

We can achieve both better oversight (through the experts + WG review)
*and* more flexibility with the "Expert Review" policy.  I don't
believe we can get there without this document unless we change the
allocation policies for everyone.

Thanks!

Alvaro.