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

"kowalik@denic.de" <kowalik@denic.de> Thu, 19 September 2024 13:46 UTC

Return-Path: <kowalik@denic.de>
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 97312C151092 for <regext@ietfa.amsl.com>; Thu, 19 Sep 2024 06:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=denic.de
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 TJEO79qBvLfR for <regext@ietfa.amsl.com>; Thu, 19 Sep 2024 06:46:47 -0700 (PDT)
Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [IPv6:2001:67c:2050:102:465::112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F60C14F6B4 for <regext@ietf.org>; Thu, 19 Sep 2024 06:46:45 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-112.mailbox.org (Postfix) with ESMTPS id 4X8cHz46BSzDtBD; Thu, 19 Sep 2024 15:46:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1726753599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LlpLC2mkZKQnzWXa1udwiTotozox4PpkUt7noBUMOzI=; b=yEouQuTrMgFI0L+L9z7Jkk4XTmPfpKX4833AhHevHxp9RbW6/V/6ieYd3cjerQceEOymDd 3N2W/EdwiCxexAyQld3kP9xfN98qxzekHCY9E2yvrBBf/pcBjTMPO8KHGuU/klvIf3lNle eU0jzF9T9cUoTVqqlDdgpNQHLqwRo1x6d61KVRq/Lw+luJGmJcaMftFJbfKV21to4dmUh4 Uk/d+cn5NF7FxHmdVdpaDDAyEBuwrvyW3b9YVSzXn3nBNCQUgO5eXbSQmCfFxjNpY9Es6C FBUZYG3DtXWqfMEdlxGZ0tKGnrixnRTFQ8PFyXvQu/NGpPdx1pXRTxy7fMAJnw==
Message-ID: <3b7ae504-fbf1-4f23-b1be-297dd5ad6543@denic.de>
Date: Thu, 19 Sep 2024 15:46:38 +0200
MIME-Version: 1.0
From: "kowalik@denic.de" <kowalik@denic.de>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "regext@ietf.org" <regext@ietf.org>
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>
Content-Language: en-GB, de-DE
In-Reply-To: <fe8d7c5f022046918b8238ddd8234f8d@verisign.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms050606090708070003070006"
X-MBO-RS-META: 6scx5gukcaekn9air1ti6bfzkgom3ruf
X-MBO-RS-ID: 1eecba29ec41ea0851f
Message-ID-Hash: CAK3NVM7GXOYOUJPCJCKNLCTX6JQQD4U
X-Message-ID-Hash: CAK3NVM7GXOYOUJPCJCKNLCTX6JQQD4U
X-MailFrom: kowalik@denic.de
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.9rc4
Precedence: list
Subject: [regext] Re: FW: 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/XQXnMDzR3YnyAvQoRfvmQ_POcxY>
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>

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.


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.


Kind Regards,

Pawel