Re: [Curdle] Time to Review IANA SSH Registries Policies?

denis bider <> Sat, 06 February 2021 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ACCF3A2BE7 for <>; Sat, 6 Feb 2021 12:56:34 -0800 (PST)
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 uAh4RmxSwddu for <>; Sat, 6 Feb 2021 12:56:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 333133A2BE6 for <>; Sat, 6 Feb 2021 12:56:32 -0800 (PST)
Received: by with SMTP id 100so3807377otg.3 for <>; Sat, 06 Feb 2021 12:56:32 -0800 (PST)
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; bh=GNPVHoww1QjmrHUruo3+UKE6o30DcDGfSh5drupDuk0=; b=lReGyS+T2Bf9PkDS39N1UFP4TtRkeTBtVdsJnq27nDEV/3Cugku/y1eJI+bHTpwx1x /4ownaSoVX3FcoqweArXNNpGVcNB43DxA7q7fDppa3Sl3kggpewYmNZNdBEnp+ztbMA/ sK7sI+hKmATWr54VTe3yuUKcJjW4W/CJPoNLdSfL4yYNnnd2VgEk3ibWS0+gSaCkLTZN qmZVvOUjgDgmSODzhLkdqIzgxhtDx20NvAe5QekWAuDmfA1KGtPE7LqAEFlxZTKyzfkw uwper1vhOhsydgvT6kp86QVZuBeMStqscnvLB2LAaDlbcXthXVqM33L+mg05chf3h8YX GSWg==
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; bh=GNPVHoww1QjmrHUruo3+UKE6o30DcDGfSh5drupDuk0=; b=dOP7t32KtqJz+7C3xXhI2x1bQTsmjyynooHDElabqoZVGAX9XHH7adJhB2Wt4NEmLC G8dCT0VUZnwr7zjhxXSGajs4TyXGPF1BOBHqfGOyiOfx5uchCE5HouSq7T42NpICulG/ 7cttpStB4dQtRh61O07UkymnrqEG0Uu9H4dNYHXvvI7cnQikVPukxNz+VYrzLfyteFpq KchQbbFsUTrQCjKjY+LBHGiI63KgHSgygh/J8K26Qh+hiOHS9KL+2rG16RzDQzeQJNfo awfpkN0gWQaEdYG0BHvMGIMsNRH+0nobT7j5+cJhxXUCJ2Km8ZQk2ZajJCXqIDGvsdRV 1vrg==
X-Gm-Message-State: AOAM531vKx+Vv18u3OTjt+y0sXhSVrgLGCisZVB1yfMivePCmAL3sxld 0zaPqbRQDZLmBOEkyDsKIrcCbH8ik7FNcC7OpQYnZM6tHvk=
X-Google-Smtp-Source: ABdhPJye1Bw7IfI6ae3gmlX8Ru6pgY5+G/f1NcJdONQO50fQ2OtLXuv5z8zuc0CFgohTagg/2CZNGaDJXfl03FDS4rw=
X-Received: by 2002:a05:6830:56e:: with SMTP id f14mr7517331otc.85.1612644991225; Sat, 06 Feb 2021 12:56:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: denis bider <>
Date: Sat, 6 Feb 2021 14:56:20 -0600
Message-ID: <>
To: Curdle List <>
Content-Type: multipart/alternative; boundary="000000000000d9d1fa05bab12b67"
Archived-At: <>
Subject: Re: [Curdle] Time to Review IANA SSH Registries Policies?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Feb 2021 20:56:34 -0000

Some general thoughts on this:

(A) When I'm implementing new ideas, it would be nice to have a more
straightforward way of registering and documenting them.

(B) Registration is needed primarily for coordination. Primarily,
incompatible ideas must avoid using the same (numeric or string)
identifiers on the wire. This primary purpose can be met without
documentation. If the identifier space is large compared to demand, there
need be no specific standards that registrations must meet.

(C) However, registration also helps discover ideas developed by others. In
this case, documentation is essential if one wants to understand and use
those ideas.

(D) So quality of documentation is important. Lots of people who try
writing specs, write specs of questionable usability without lots of
guidance, review, iteration, and cajoling from others. The spec writer
experiences this as suffering. However, this suffering ensures a useful

(E) Nevertheless, there is suffering. Therefore, if the process is too
onerous, the spec writer learns to avoid it.

I'm thinking (E) is a problem for the IETF - the registration + spec
polishing burdens are onerous. Two years to publish an RFC is a lot. It
vastly reduces the number of specs people are willing to write.

For most things, I'm not willing to go through this effort. Instead, I
might publish an internet-draft, and then make no effort toward an RFC
because the draft, even though informal, is discoverable, and costs 5% of
the effort of an RFC. There are lots more things for which I'm willing to
write an internet-draft, than things for which I'm willing to write an RFC.

I think the IETF could ease the registration and documentation burdens to
increase the likelihood that:

- Registration happens, for coordination purposes.

- Documentation is published that otherwise would not be, even if it's not

I think there are opportunities here that are currently being missed.
Changing some of the SSH registries to expert review could be a step in
this direction, but it depends on what the expert review practically looks
like. If it's going to look like Peter described, where you can't actually
reach the experts, then I'm not sure if it's an improvement. :)


On Thu, Feb 4, 2021 at 5:44 PM Peter Gutmann <>

> Phillip Hallam-Baker <> writes:
> >Restrictive registration requirements contradict the principle of
> >'permissionless innovation'. If the IETF is the place you go to get
> >permission to innovate, we are doing it wrong.
> +1.  To give a real-world experience of "expert review", when I tried to go
> through the process on $unnamed-wg there was an experts group that you
> couldn't contact who had a non-public mailing list where decisions were
> made
> in secret, but that didn't matter since there was no way to contact them.
> Eventually it got sorted out by one or two people involved in the process
> going out of their way to help, but when done as it should have been the
> process was more reminiscent of Kafka than the IETF.
> Peter.
> _______________________________________________
> Curdle mailing list