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

denis bider <denisbider.ietf@gmail.com> Mon, 08 February 2021 16:47 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F983A11CB for <curdle@ietfa.amsl.com>; Mon, 8 Feb 2021 08:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: 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 JYLhVokslBry for <curdle@ietfa.amsl.com>; Mon, 8 Feb 2021 08:47:30 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 398263A11B2 for <curdle@ietf.org>; Mon, 8 Feb 2021 08:47:30 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id e5so7932096otb.11 for <curdle@ietf.org>; Mon, 08 Feb 2021 08:47:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4EeR81BZYnBv4XQLTL0EmDVo07hoCxg8X0hIIs6Oz4I=; b=jN2enV+tUadFv3E9fvq9TnCsAHBmDpqiDKowqTSkxPn0lTeft6EQJftNbW4vrG1Yam ZpO5y75/ep9VVs8c1JSlHmRAuNCA6w7VXvjhaOsN43uiu1HUwrLSMaVkLSMy3L2yJJk9 ejHVkhDjNpNyzAN1vINXjm56V7Ro9X0UdPX8Br4NEQkMaui7VEZdbgmvz9iYsNbIOf3Y z5XF9rzp30lwuh+vjtRkfDFQveQHje6tEv6l+1DE5dQH/LKmOUMiGj5GpG3/9hoZy5yR AVZd0QPVJFt6+x3GZsIqlDz5fa3S/iMcwS2B6UNMvayP0TesEOVShjrxajmB8C5cS3Nc dlvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4EeR81BZYnBv4XQLTL0EmDVo07hoCxg8X0hIIs6Oz4I=; b=mONK9vet4+0/RfbCedGoB8yHr7jZw4jhRUwJvZq2fp3bkfKr6cMaTfzPYWPE5hYpf5 N38gLLTiQgv4FIB8zs4eO4FjzUQx4fVlCrL8+MVbIHd9yXwU/cX+KAW7jI1qtuA5JmHE rkF6zISyxcAU48MpcgAgu62hZ78OdNr0kSXdCL/35LVWWNG7HFygbR7f7rPkPT7Y3uYH u+vxQ+4lFApFRw+qjbstyrm+8Qyk+OlMcoON98chaPSiCbcv8UpPAESTQKu5uox+pJxi WMosc9FEMCW3bqW5j6eiXpWTXizPqn4OzgEchp96YeZn8sQokIU2+RQbIfqEaP/ph+Gd NywA==
X-Gm-Message-State: AOAM5336j8+VUbdBIkp3UfZGM4HdkNL0aj06KOmwfJdDxZm0lBhB46TW ESVs5upGNHA8Nz8GW9Kx0X9DTFXl50Jl1an51kU=
X-Google-Smtp-Source: ABdhPJxxyl/CHJqYmJSPoSjt3fRHkJ/V/nptre+mc6ZX7tIu0jXELjmF815HFV/3Kqp5U9WPEXiJi6smqr25CqfeqDI=
X-Received: by 2002:a05:6830:573:: with SMTP id f19mr13075851otc.117.1612802849425; Mon, 08 Feb 2021 08:47:29 -0800 (PST)
MIME-Version: 1.0
References: <A77E7858-C4ED-4DA0-8015-5E67EB921144@sn3rd.com> <02E82091-15F9-4C36-96AD-1F88CC2E5594@akamai.com> <CAMm+LwgUPBiZ6FoiBir9ByFPFxgcWtMGVKC4LPNVM7EdCaVoDQ@mail.gmail.com> <1612482228184.63328@cs.auckland.ac.nz> <CAMm+Lwh7awZ2ope-7LjafZSH8K9n1b3Z39iRUmVBdWp-ts3d2g@mail.gmail.com>
In-Reply-To: <CAMm+Lwh7awZ2ope-7LjafZSH8K9n1b3Z39iRUmVBdWp-ts3d2g@mail.gmail.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Mon, 08 Feb 2021 10:47:18 -0600
Message-ID: <CADPMZDAx1rDonx80x6qYhghirRBcgeZMNHOuu6BV+=QpONecqA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Curdle List <curdle@ietf.org>, Sean Turner <sean@sn3rd.com>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eecdf305bad5ec66"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/qiXhEe8AdmzLjdL7bwF1AT7KYR8>
Subject: Re: [Curdle] Time to Review IANA SSH Registries Policies?
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 16:47:32 -0000

:D

Well argued.

The thing with a person or group getting out of the way is that this
vacates the opportunity for being in the way. The opportunity continues to
exist and becomes open to the next person.

This is generally the problem with power. Things work better with
coordination. We're therefore willing to pay a substantial cost to
coordinate. The role of the coordinator is a form of power. This power
works best if the coordinator coordinates, and otherwise gets out of the
way. But to use power in restrained ways is to serve, and to serve is a
burden. Therefore, the people who apply for such positions are (1)
reluctant volunteers who would serve, and (2) folks who see it as an
opportunity to "lead" and "govern".

Reluctant volunteers will gladly step away in favor of those who have more
enthusiasm, and those who have more enthusiasm are the ones who would
"lead" and "govern". And that's how we simultaneously want and need
coordination, but somehow it always devolves into some kind of tyranny.

Speaking very generally, the IETF is just a microcosm and a special case.

On Sun, Feb 7, 2021 at 9:41 PM Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

> +1
>
> Registration processes can very easily turn into ring kissing
> requirements. And especially so when the authority is a voluntary
> organization.
>
> Lots of people get really, really excited at the idea that they are adding
> value by preventing work that might lead to vague, consequences that they
> can't quite put their finger on.
>
> And then when people go through the process and end up waiting six months
> for those people to make up their minds, well we are a
> voluntary organization so people should thank us for the very important
> work we do.
>
> I have a rather different view. I think that when someone puts themselves
> in the way of someone else's critical path, they are making a commitment to
> deal with the issue expeditiously and if that isn't possible, the answer is
> to not make things critical path.
>
> Given the number of times we have people pointing out the IESG are
> overworked, we should look to get out of the way as much as possible, not
> stand athwart the tides of history yelling stop.
>
>
> On Thu, Feb 4, 2021 at 6:44 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
>
>> Phillip Hallam-Baker <phill@hallambaker.com> 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
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>