Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Tim Wicinski <> Tue, 07 July 2020 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E14D3A0823 for <>; Mon, 6 Jul 2020 18:08:04 -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 GsBF3ll8ZQH9 for <>; Mon, 6 Jul 2020 18:08:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FC4A3A0822 for <>; Mon, 6 Jul 2020 18:08:00 -0700 (PDT)
Received: by with SMTP id h13so12544840otr.0 for <>; Mon, 06 Jul 2020 18:08:00 -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=6rTvaXY5k/Pq02XSHahwJ7cSo+GmBzAmQES+KL8fW/I=; b=fQCdIpp9EXDoZ1ejzu9tSFNZhCk2ttyLTjhiAgUjyyIdjAK1n4LVNWmuUqbfesIcd1 7Sl+sgOo5nPerfg2Aua25d6onCvEdxcUGvMS8R1tEqwGMig3PN3JyFUZkdPdQmId6uny 6Msvw92qi7Y1A2DkMmLKSexigBpzzHJ0UQWe0HEf8XF4SNTI5I99XxuXxeH0z96KiDrl XjtI/LKRnSs2iKWD154lFTBA50PTKRvJyQCLIB3g56/16dT0Cib3rmDYfysxZQn3DKi3 8nHT6hfuJOivDRjfEOdIvROx9oWqfZZNF6FGxL95aSeQDIC7Zb/4N26sDV1zWvokKnSX Mn3g==
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=6rTvaXY5k/Pq02XSHahwJ7cSo+GmBzAmQES+KL8fW/I=; b=kp0cHc0/xScQoyhesCtv7WtDrtENZM7CYMQS409xdAnVNFFyWVwf3aZQEjl6BEqmOs l2LYtMvTaIWETLcHQ89ZGY+nxQI7zPxXVy3M/8wtUf+Gm8uE6y+Rv3dsqra7H7wrfUXK 8QrJiGKcnWj87nluL4cCM0D6aLbgF8mo7kyzGnD1A5naDGLrubXsPz70NC6Icu/ti+YI YJYxlhe2VnQkVgA1DpdZ29YY+XYkHWcnNR0ZCSl7HVs0HOhFFG3kMWto9F9F9WhFrSGB 9t6mijH90d0ek/98ZNC6drVRGVD5e/F39VXoXG2YKChDC+KhwvJKaa1KsbJ59J0cflVO 0xsQ==
X-Gm-Message-State: AOAM530Ip+BIQhcMoHxg7d5AN/nx/4ptFoWaKNDTPPdmU5neW7j7UlI6 cddizSmE+2/b9hW9+R34/LN6LFeq1gOfqrPorUo=
X-Google-Smtp-Source: ABdhPJxYG+Y2zaskTdLUE5Xm62MwuyfGLf+9xvfq1Iq/c29uMToeoZXLzEg7updCokrf5kwd/g/F+zKjscwtCeHLJrY=
X-Received: by 2002:a05:6830:4008:: with SMTP id h8mr44945864ots.158.1594084080125; Mon, 06 Jul 2020 18:08:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Mon, 6 Jul 2020 21:07:48 -0400
Message-ID: <>
To: Wes Hardaker <>
Cc: Paul Hoffman <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000568ced05a9cf9f72"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jul 2020 01:08:04 -0000


I've been going over the CfA comments, and discussing this with my chairs
and Warren, and
perhaps the best way to walk through the logic in our decision is to work

The authors are requesting a code point for their algorithm in this IANA

To receive such a code point a "Standards Action", which is defined as:

    For the Standards Action policy, values are assigned only through
    Standards Track or Best Current Practice RFCs in the IETF Stream.

Which means that 1) Informational will not work; and 2) Independent Stream
will not work.

In the excellent discussion on this, what seems to be the underlying
consensus is
the need to publish the document to establish the code point, and document
it as such.

To not adopt this means, the implementers could easily pick their own
There was also discussion on updating the table in
(implementation recommendations for DNSKEY algorithms), and here seemed to
be some consensus around MAY

There was also an orthogonal discussion around changing the registry from
"Standards Action"
to "RFC Required".  While this seems to be a simple procedural move, I fear
that doing
so haphazardly without understanding the operational considerations is
wrong (Remember, We are DNS OPerations)

Mr. Wouters made the very correct comment that "no one outside the IETF
really knows the difference for RFCs anyway."
This was something I was reminded of all too well during the DNS RPZ

Summary:  Adopt as Standards Track because we have to add text to the state
as such.  We will not spend a lot
of WG time on this document, and Warren and I will end up doing the heavy
lifting on all the process portions.


On Wed, Jun 24, 2020 at 6:42 PM Wes Hardaker <> wrote:

> Paul Hoffman <> writes:
> > If the WG wants, this short draft could be a WG document.
> Yes please.
> --
> Wes Hardaker
> _______________________________________________
> DNSOP mailing list