[regext] Re: using experimental to move items forward

James Galvin <galvin@elistx.com> Wed, 10 July 2024 20:55 UTC

Return-Path: <galvin@elistx.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB23FC151547 for <regext@ietfa.amsl.com>; Wed, 10 Jul 2024 13:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=elistx-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoU4E0-G0AX5 for <regext@ietfa.amsl.com>; Wed, 10 Jul 2024 13:55:26 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091EFC151527 for <regext@ietf.org>; Wed, 10 Jul 2024 13:55:26 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dff1ccdc17bso204019276.0 for <regext@ietf.org>; Wed, 10 Jul 2024 13:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx-com.20230601.gappssmtp.com; s=20230601; t=1720644925; x=1721249725; darn=ietf.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=W5hcnj3OGFmW6Ts0Bi9P7RoySBQDq7sz45WgYRx6VoA=; b=GjB4LJubDOh4+OtkWZqAot9zfxEOBYyZ+oUD/NaKQWogGt6quEV+Brp1H0xrZHrBOp pVZQRQCL73NQ3xhVTnrFOCz8PkAWFSyQPMN8/jyStGbCqPUN7GktgzkCv2OvrbZKiQ+p BtKwx2I2IH2rk05NZHIeNfa9ixxnFoanEIOCCpntlTuJZnOGKJR1l99nOyRp54JOH5bH O+ls7WAO1DtOc2rwEKRefWpUqFmBGB3a7YkS+6hoAyInk2M3iqMy3CNPNViCxm0LTtfH Or3m6TNElRVpodgQnxrWLNvYmkDvM/BYkQZ/H8+G5c/nWwEtWfslknItGHv0VIRp5rpk eR9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720644925; x=1721249725; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W5hcnj3OGFmW6Ts0Bi9P7RoySBQDq7sz45WgYRx6VoA=; b=CmExtlomNsQhNMSFbFyDth9XQzi+amHGFJ+1GE1ZiyE3XRfg8j9BT0NQ3VbasCYgA6 ieQ3pQq8b3qlM6JZTFUDA6/k5Wt94es2zUrgNxKpAkjHxN+4fu+y8yYW2JVwCeIHM0rW WLHLtFpeyTlUyajecixztUtwE9Zhbzk/rt9tY1NTZtNoYOraWso+N7bNzoJ9Nt3FZSXx waBkqEJiMdCNaUqkPyZSvQRXPdxdWXHyfgLaowIhlCwT4p7A72XMEj0qQ7EgaEVWgGm0 xbVZgFopwQP36ihN7Es09JVfSZnsW27gRZSQfMU2n7nNz81ua8R4ByH9ObGoYhiMnt3l 0SHA==
X-Gm-Message-State: AOJu0YyJvU76eMn5Jjbjyda1X2AdPHiEK8CIY9rscbsLQUsM707aDaeR BoLu/TAEWrmOXLBz4RwBW2jQ0jZKaaTeKDxHkfixR8SIgm15ntFC06PBU47HFVCnEZAAE5hPs51 N
X-Google-Smtp-Source: AGHT+IHSEURsufHeVuKnuJhxFRxlyUT3M3mMp7n3GkmjnGAHNR/FdO8Gpf2pLqNvqzbvo24fJAb1vQ==
X-Received: by 2002:a25:9902:0:b0:e03:a248:7dd3 with SMTP id 3f1490d57ef6-e041b061cb3mr7880334276.23.1720644924954; Wed, 10 Jul 2024 13:55:24 -0700 (PDT)
Received: from [10.0.0.20] ([2601:147:4500:cf70:503:7978:bd50:bc2b]) by smtp.googlemail.com with ESMTPSA id 6a1803df08f44-6b61b9c47c9sm20075176d6.8.2024.07.10.13.55.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2024 13:55:24 -0700 (PDT)
From: James Galvin <galvin@elistx.com>
To: "Andrew Newton (andy)" <andy@hxr.us>
Date: Wed, 10 Jul 2024 16:55:24 -0400
X-Mailer: MailMate (1.14r5937)
Message-ID: <ADE83228-5214-4E37-9D66-46D905972E9E@elistx.com>
In-Reply-To: <58a37208-ca17-4dd5-8d7c-c112fb3438f9@hxr.us>
References: <58a37208-ca17-4dd5-8d7c-c112fb3438f9@hxr.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: ID2OVVNSML2QYAOKE7UP7IUXV7KELZ3B
X-Message-ID-Hash: ID2OVVNSML2QYAOKE7UP7IUXV7KELZ3B
X-MailFrom: galvin@elistx.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: regext@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [regext] Re: using experimental to move items forward
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/MY0JRvlwkMkxorqWzog8SpHroJU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

I’m happy to provide some during the “admin” portion of our meeting for a discussion of this.  If you want to kick this off that’s great too.

As co-Chair, I will observe only that if you want a “standards track” document then whatever discussion is happening or needs to happen in REGEXT is appropriate.  In fact, if that results in delay, I would be inclined to lean on the side of that being a good thing since I would hope that means the group is looking at interoperability issues.  If not, then that’s something we should address on a case by case basis.

As far as the working group blessing something as “experimental” or “informational”, I’m not inclined to support that.  I’ll remind folks that both EPP and RDAP extension registries are open, meaning anyone can publish a document describing their extension and get it listed.  You don’t need any special permission.

Of course, getting the working group to acknowledge it does mean the IETF gets change control, and perhaps that’s a desirable characteristic and thus adding this process option to how we work would be good thing.

So, let’s plan to talk about it at IETF120.

Thanks,

Jim



On 14 Jun 2024, at 6:22, Andrew Newton (andy) wrote:

> Hi all,
>
> When I look at the DNSOP working group I see items like CDS bootstrapping and generalized NOTIFY are nearing completion. They have even spun off another working group recently. Comparing that to the progress here, it seems that in REGEXT we don’t make as much progress.
>
> Given the different perspectives, I’d like to propose a change in our working group process inspired by mailmaint [1], sidrops [2], and idr [3]. The basic proposal is to adopt the SIDROPS/IDR thresholds but with a lower bar for all RDAP extensions: before publication on the standards track there must be at least one interoperable server and client implementation documented with an implementation report published on the working group wiki [4]. Otherwise the extension may be published as experimental with the proviso that it could be put back on the standards track once interoperability between a client and a server is documented. And in special circumstances, the chairs could waive this requirement.
>
> Note that in the SIDROPS and IDR examples above, there's nothing in the working group charter that requires these interoperable implementations. We might be able to do this in REGEXT without a charter change, too. Following their lead, we would publish this proposal to the REGEXT wiki [4].
>
> -andy
>
>
> [1] https://datatracker.ietf.org/wg/mailmaint/about/
> [2] https://wiki.ietf.org/en/group/sidrops
> [3] https://wiki.ietf.org/group/idr
> [4] https://wiki.ietf.org/group/regext
>
>
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-leave@ietf.org