[regext] Re: normative language and references in draft-ietf-regext-delete-bcp

James Galvin <galvin@elistx.com> Wed, 16 October 2024 00:19 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 17A1EC1D530E for <regext@ietfa.amsl.com>; Tue, 15 Oct 2024 17:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 iQceCu_taAMr for <regext@ietfa.amsl.com>; Tue, 15 Oct 2024 17:19:09 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDDEC14CE5E for <regext@ietf.org>; Tue, 15 Oct 2024 17:19:09 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-7b13ff3141aso52230385a.1 for <regext@ietf.org>; Tue, 15 Oct 2024 17:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx-com.20230601.gappssmtp.com; s=20230601; t=1729037948; x=1729642748; darn=ietf.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=jccNTNyocBU20Qt38hx/cZVkS/TcRlPpRPqai+P53h8=; b=0TSuI06a6bTNBYhixAPqSab6/n7ZnCAwaVwCpJtx0z7GTgliGwMFP5OuPrGN1TSxfX hvtWOp/VoYgZYVjc1uiaY+X5WZM8ksobTOFXzGve4+ck7mbmfTKXCoovuqLlyog9vKfk ltznwAPfDHryZGkAJIkCaOs4YwbIBG1e8gJtQSP3W4Ql8wM8YVwqV0J1hpuk8pi0O7wT 4ir5cTkJWlhJUTL/ifyaQINhPQ/nmBmtASS1ta4iYFVS5op1EyySaoVGoTRKqK6KcSgr t/ZQH5IX58Lq7JAf06afbCvFj1zRx1UQuqkperh4s2JfZLkSMVGFpsydwlG80vVQ40SP XcNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729037948; x=1729642748; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jccNTNyocBU20Qt38hx/cZVkS/TcRlPpRPqai+P53h8=; b=fZ/AjroKD3+g+tR8/SQMxFXrO/SEi8XgNbG4K0Sft+Q3L2WEyyyvxjZj4J4gQ3am6t eBqks0ocrQVpBZdt9I2gxlNlbTK3q3FxpGDd8Qrr/j/n49CyDnyjvK5M6BD6jyLp6Ep3 t4GImAgmUpQMZWC31UrRhpc4WwNWHmWHjXWFOabw9UBRZHj6BScEC+dEeecGjZfSe3HL N2oMCZn0Vlgho1ZS/1FnJjB3Yz1EMSiBq+Du1T0sWwucMRGsDbN8dgew582eFwIEkRWw Ug3MGNp/KE50iFJRr72TVKf7WU+YO9oTPz/PkTGBp2NGRkxcXMiP3xbwDdU2sxqaLs+9 A+rg==
X-Gm-Message-State: AOJu0YwkBG/cTIXt5kyYHaaeM/ypvPPyuR54cAKQDwN5d4RckTCbUeSs ZjL1VSk5cYKid/jgFh6HIIqAY7Cdn+GJeRVa4GVUFhqmbNuH/VeJyKz9gnF6GeF6cSF+TXRL/bc Z
X-Google-Smtp-Source: AGHT+IEcOcfqhRBtpxNM5PmYWIj5mIy/K4/vr7TTcb98/WZBR/Eo3S7Ia5c9xrwN5wcl87f8gc7Sfw==
X-Received: by 2002:a05:620a:459f:b0:7ab:3311:f0e with SMTP id af79cd13be357-7b11a386ae0mr2500189785a.33.1729037948118; Tue, 15 Oct 2024 17:19:08 -0700 (PDT)
Received: from [10.0.0.20] ([2601:147:4500:cf70:3002:c3f0:839c:3552]) by smtp.googlemail.com with ESMTPSA id af79cd13be357-7b13617a452sm122875785a.67.2024.10.15.17.19.07 for <regext@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2024 17:19:07 -0700 (PDT)
From: James Galvin <galvin@elistx.com>
To: regext@ietf.org
Date: Tue, 15 Oct 2024 20:19:13 -0400
X-Mailer: MailMate (1.14r5937)
Message-ID: <D10F8F1A-B1F2-4DC8-9A5E-592858A9C6AC@elistx.com>
In-Reply-To: <93931fca85334496b2d74bcd6cd3ee26@verisign.com>
References: <90b13eb0-0269-4e4a-a3bf-b82dc54e79f3@hxr.us> <c3decf58f1f04e47a47ab1f8b32d5d4a@verisign.com> <d697e4ce-9cec-4231-bd71-7ce3de602581@hxr.us> <ca771eb844344503a52ac3e1d036b606@verisign.com> <91905f6d53cb4f29978eefccb8f0889f@verisign.com> <c58d31fd-cff5-4998-b009-36b1e0a201f3@denic.de> <fe8d7c5f022046918b8238ddd8234f8d@verisign.com> <3b7ae504-fbf1-4f23-b1be-297dd5ad6543@denic.de> <93931fca85334496b2d74bcd6cd3ee26@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: FMVB3THZB3I52SAK4J53FEPEWUIF2KHC
X-Message-ID-Hash: FMVB3THZB3I52SAK4J53FEPEWUIF2KHC
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [regext] Re: normative language and references in draft-ietf-regext-delete-bcp
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/3_rndLPBOiXfcMx2aifD_ae9oqs>
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>

Speaking as co-Chair, here is where I believe this discussion has landed.

From a consensus point of view, I’m declaring the working group consensus to be that v08 of draft-ietf-regext-delete-bcp is ready for submission to the IESG.  We’ve been through WGLC and we’ve had quite some discussion since then but I do not believe the changes have been material and require a second WGLC.

However, we do have one significant dissenting voice in that consensus.  In our working group we only have a few people who are very active and we’ve been fortunate that we typically have full consensus amongst those who speak up regarding a document’s status.  The Chairs are sensitive to alternate points of view when the number of those who engage is frequently small.

The Chair’s suggestion is to acknowledge the point of view in the Shepherd Writeup.  We think it’s important so that if questions arise within the IESG or during IETF Last Call, particularly from anyone who happens to check our mailing list and notices the extended dialogue, we are being clear that the working group considered the question and the document represents consensus.

Andy Newton, as Document Shepherd, please update the write-up accordingly.  Upon completion the Chairs will review it and then submit the document to the IESG for publication as a Best Current Practice.

Thanks to all for your passionate and detailed discussion of the questions.  I know our work is better when so many of us are so engaged.

Antoin and Jim


On 19 Sep 2024, at 13:48, Hollenbeck, Scott wrote:

>> -----Original Message-----
>> From: kowalik@denic.de <kowalik@denic.de>
>> Sent: Thursday, September 19, 2024 9:47 AM
>> To: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] FW: Re: normative language and references
>> in draft-ietf-regext-delete-bcp
>>
>> Hi Scott,
>>
>> On 12.09.24 14:39, Hollenbeck, Scott wrote:
>>>> -----Original Message-----
>>>> From: kowalik@denic.de <kowalik@denic.de>
>>>> Sent: Thursday, September 12, 2024 2:29 AM
>>>> To: Hollenbeck, Scott <shollenbeck@verisign.com>
>>>> Subject: [EXTERNAL] Re: [regext] FW: Re: normative language and
>>>> references in draft-ietf-regext-delete-bcp
>>>>
>>>> Hi Scott,
>>>>
>>>> I think I am missing your comment on this issue from the previous thread
>> [1].
>>>>
>>>>   >> I am still not sure how useful it is to have normative language
>>>> as such in BCP, especially if it's only used in the section 6, which
>>>> refers to other sections like 5.1.4.3 which in turn does not contain any
>> normative language at all.
>>>> Whether it's a MUST or SHOULD is likely a secondary concern and here
>>>> at least I would like to learn the logic behind the change.
>>> [SAH] The value of normative language in a BCP is described in Section 6 of
>> RFC 2119:
>>>
>>> "Imperatives of the type defined in this memo must be used with care and
>> sparingly.  In particular, they MUST only be used where it is  actually required
>> for interoperation or to limit behavior which has  potential for causing harm
>> (e.g., limiting retransmisssions)"
>>>
>>> "or to limit behavior which has  potential for causing harm". The guidance
>> found in Section 6 of the draft uses normative language in the spirit of limiting
>> behavior which has potential for causing harm. As it says in the draft, "with
>> minimal undesired side effects".
>>>
>> [PK] This was not exactly my concern.
>>
>> Section 6 refers to 5.1.4.3 as one of alternatives of MUST.
>>
>> 5.1.4.3 reads: "EPP clients MAY rename the host object to be deleted...". This
>> is followed by "This requires that the client maintain...". I would expect some
>> normative language here to be able to follow the recommendation of Section
>> 6.
>>
>> The same applies to the other alternatives of section 6.
>
> [SAH] Pawel, at this point I'm inclined to wait to see what our chairs say about document readiness for AD review (hint, hint, WG chairs) before we make any more changes to the text. Having said that, I just read through Section 5 again. It's titled "Analysis of Practices for Domain and Host Object Deletion". If we accept that title, I'd actually prefer to *remove* all normative language from Section 5 so that it remains focused on *analysis*. The normative language can be used in Section 6, "Recommendations".
>
>> When you mention "limit behavior which has potential for causing harm" a
>> Recommendation with a normative MUST NOT to practices which actually
>> cause harm would be of benefit from this BCP.
>
> [SAH] That may be worth doing.
>
> Scott
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-leave@ietf.org