Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)

George Michaelson <> Wed, 09 December 2020 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8387C3A0127 for <>; Wed, 9 Dec 2020 15:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 43gxbs8SCG1O for <>; Wed, 9 Dec 2020 15:22:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B89B93A00D9 for <>; Wed, 9 Dec 2020 15:22:51 -0800 (PST)
Received: by with SMTP id s11so4518256ljp.4 for <>; Wed, 09 Dec 2020 15:22:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zGqOLCdndYxjC34PqVNqfvIQhJiFXZrFYHWhatl0oKI=; b=NqbxCkGziGTvXzx7IVKcOz4KPJAKra8l90BCGYgPQvv6HkgVPpWHXW0djwFhdrZrDV 0Yfg5ZqQ29rzqyd1Lw/vi2dz/vU7lN7IJJ2JcTrOoU97ZZftet9BtGAeqToL18DFVyJW tQOI8T2j456N3fVkArEQdkd3SVAVmQvbx84BxXsMRT/+1IvJarn4OP9HvR4CFSYD2T+g f3dcBGgC28crtEatb5nsjoowMZr50dmzFojSnIys4KQCfqRbYsfPTsBaluETn66YUue2 klw82Sc9rvhhZVE+U1tiMOxVbV+fDJs98konHQy9QA25Rb6UPa6P4ApYikbDaLyBLJLe g7hg==
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:content-transfer-encoding; bh=zGqOLCdndYxjC34PqVNqfvIQhJiFXZrFYHWhatl0oKI=; b=KBSANAoE6QO57uUibtQ/LiwjltviE4XEWfCGOWlq+tjS6LMrAAPuBrfVPCFHC1X441 pC5tLX+SVsX5AD9/np24iQ32IBS6v/Ox+DU0xI+5wF958HwgqAoTDd+oiWoLl15TrG6m 6X25uX66VB8ottiiAuGO4ngcMWFhtHCNdgS0l4upIDLiT8IResU0JrZAzysdIn93J+G0 Mshj/KOojiZ39/G7QGSXi13degDyTsNjT99OWeoKyKu8NIfok8X4MzDWZxN5jcpxyB5m A7jb+hzPWlou6YTMARe03EB3lIdBkIS6F/v/6bj+i5pocbkBZpsTmu+sh9fPyHjzr+JE VC5g==
X-Gm-Message-State: AOAM530ziptbxbB9nwGxqeJoVd+titpIyD/Oxwq0D561+UPdC7ES3LF/ vUp++f/HftgQV54TGWMUTOS78TTAkVIRCnTTNr0pKQ==
X-Google-Smtp-Source: ABdhPJwNaRbd4hFltbREIGUtfFFCsW30tDarzW6DvftzeEl5foRxEI3X3nYdRsCJvXIxYnHkCa5NFaiEvuYC8OuokbY=
X-Received: by 2002:a2e:154c:: with SMTP id 12mr1958919ljv.210.1607556169801; Wed, 09 Dec 2020 15:22:49 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Thu, 10 Dec 2020 09:22:38 +1000
Message-ID: <>
To: Joel Jaeggli <>
Cc: Tim Bruijnzeels <>, SIDR Operations WG <>, Job Snijders <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2020 23:22:57 -0000

I truly think RTA has a case to be here. It's aiming to provide B2B
pre-provisioning assurance, and other services to Operators who have
delegated Internet Number Resources. That is why I asked for adoption

If there is a better fit in an OPS WG, I'm happy to take it there if
the AD or WG chairs prefer, but I think SIDROPS makes sense, not the
least because "here" is where it was previously discussed and

Given that we're heading to a registry for .3letter code assignments
for file types in Manifest and Repo, there is a meta-question lurking
here: What process do people want to adjudicate additional types into
the declared registry?

Personally, I think where they don't go to routing, It is low pain to
just admit an OID. If it has consequence in routing by intent, or
would alter validation models, VRP and ROV Then it demands more
discussion since it heads towards flag day consequences. If we made
that a conditional bar, then we could defer a process to IANA as "if
the submitter says its not routing, but is RPKI signed, then it should
be ok" and have an evil-bit model. (I know, but.. )

I also truly believe RTA doesn't do this (alter routing directly). We
did not expect it to alter validation outcomes for the issuing CA, we
intended the objects to lie outside of RPKI Repo space except for the
CA certificate chain issuing the RTA detached signature object. But,
it MAY appear in a repo., so it SHOULD be understood to have no
consequence for being unable to be parsed: it wasn't meant to alter
validation in routing like that.



(sorry if this is deemed to be thread-hijacking)

On Thu, Dec 10, 2020 at 9:12 AM Joel Jaeggli <> wrote:
> On 12/9/20 05:24, Tim Bruijnzeels wrote:
> <snip>
> ...
> >> In the current charter sidrops does not intend to produce standards track documents, with IETF and working group consensus being output as BCPs when the weight of demonstrating consensus is required.
> >>
> >>  That is a challenge in the case of for example
> >>
> >>
> >>
> >> And one that should probably be more explicitly included if we are amending the charter. If we take on the protocol specification maintenance here there absolutely we should require interoperable implementation for standards advancement.
> >>
> >> requirements text around interoperability testing is good, but it needs be expanded a little to let us do the protocol maintenance, which we generally would have ascribed to IDR under the original charter.
> >>
> >> I hope the current AD will revist this.
> >
> > I believe that it would be good to extend the sidrops charter to allow it to produce standard tracks documents *and* require two implementations for that track.
> >
> > While in case of ASPA one could still argue that this could also be discussed in IDR (or perhaps just be discussed there as well), I think there is other work here that is not suitable for IDR. It may not be routing related (see the RTA document for which adoption was requested), or talk about the RPKI infrastructure itself (mft-bis / deprecate-rsync / ..future work).
> I tend to agree, charters are meant to be amended when taking on new work.
> >
> > Tim
> >
> _______________________________________________
> Sidrops mailing list