[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

"kowalik@denic.de" <kowalik@denic.de> Wed, 19 June 2024 10:38 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 44C7EC180B7A for <regext@ietfa.amsl.com>; Wed, 19 Jun 2024 03:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 xATRSZuOxVcX for <regext@ietfa.amsl.com>; Wed, 19 Jun 2024 03:38:03 -0700 (PDT)
Received: from mout-b-203.mailbox.org (mout-b-203.mailbox.org [195.10.208.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 25DECC1E723F for <regext@ietf.org>; Wed, 19 Jun 2024 03:37:05 -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-203.mailbox.org (Postfix) with ESMTPS id 4W40Rc3kWNz9v93; Wed, 19 Jun 2024 12:37:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1718793420; 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=oE0PBg/oYafTC7hbsA49p1U/HsGksfN0qrnER+zdTkw=; b=ecXDZuTjbMwgBK0CXX8hxYznhlcZI6CDzsYRxBlfOPlW9rO+QCzrhOaKH+YORujuKlYJj4 1t1WsHwgsI54PYPxD3GaHe/Kw126Rdc7edI5i41+3pMO6maGMtO2+s6i/9moqqTJdmQm7t Jv4fB66KNFxy/fwljLIQMuCwCgFD/IblIMxAX3pFGrnuwSUHb0zEoyMsvybKvaVyWgktKa K4CkaQFsDVc1oGORhVTsu5t9RNiOgm10CtE/qJKwXEkYzV0u+f8/NbAdvNf+vRPqxR3ZVY k1wgAhwi4SlntDTu+3bfJaMDFgVyv1SGzXQMV80BDBA4oL9txyPjng7ekdh7Vw==
Message-ID: <2c440941-492f-47b8-a81c-903e120556a7@denic.de>
Date: Wed, 19 Jun 2024 12:36:58 +0200
MIME-Version: 1.0
From: "kowalik@denic.de" <kowalik@denic.de>
To: "Carroll, William" <wicarroll@verisign.com>, "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=40verisign.com@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
References: <591E988C-2F3E-45CA-9E43-874C50CD0F5B@elistx.com> <a3b3ef1e-0fb5-44d5-bae0-1209acabfc02@denic.de> <8b50206930d040cca57dfeef1d0b5144@verisign.com> <42e9b5c1-a064-40b1-af7a-2e55110c2abf@denic.de> <fcf99aa6d7ba45d9a55defdd3f0281a4@verisign.com> <ED42993C-45F0-4762-B168-38F3F72803BE@verisign.com>
Content-Language: en-GB, de-DE
In-Reply-To: <ED42993C-45F0-4762-B168-38F3F72803BE@verisign.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020307060804020603090903"
X-MBO-RS-META: 48ox35accdpr9a4i9hgbgtkakyy4o5fk
X-MBO-RS-ID: 8fc07837b8eafdb6ba4
Message-ID-Hash: PBRWC6DTBKIKVCAIPBTXCJ325OGMQNFC
X-Message-ID-Hash: PBRWC6DTBKIKVCAIPBTXCJ325OGMQNFC
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: WGLC: draft-ietf-regext-epp-delete-bcp-03
List-Id: Registration Protocols Extensions <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/7p4oM15hwhx3Dq2WNmRCd-dEuvQ>
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 Bill,

TBH I didn't know of the structure in 00 and I must admit it's a way 
more straightforward to follow, especially with "practices to avoid". 
This determination was not that obvious to me when reading the current 
version with each method having Benefits/Detriments section. And I think 
this is the value I would expect from BCP.

Just thinking, that maybe the best of both, taking into account that 
Section 5 only hast 2 Subsections, would be to have the split "practices 
to avoid," "best current practices," and "potential practices" under 
each of the subsections? This would keep similar practices together and 
still be very straightforward as to what is to be avoided and what is 
experimental.

Kind Regards,

Pawel


On 18.06.24 21:25, Carroll, William wrote:
> Pawel,
>
> Thanks for the feedback and for catching the mismatch between the abstract and content.
>
> About the suggestion to split section 5, the 00 version of the document split out practices into "practices to avoid," "best current practices," and "potential practices" sections. We found that organization made it difficult to keep track of and compare similar practices across the sections (it required a lot of jumping back and forth), so we reorganized it to the major categories ("renaming to sacrificial hosts" and "deletion of hosts"). I would prefer to keep the current organization but am open to other ideas.
>
> Thanks,
>
> Bill
>
> On 6/18/24, 1:43 PM, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org <mailto:40verisign.com@dmarc.ietf.org>> wrote:
>
>
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Section 5 already identifies the practices as observed or not, but we can add clarity by splitting it into two sections. We can also update the abstract. Thanks for the feedback.
>
>
> Scott
>
>
>> -----Original Message-----
>> From: kowalik@denic.de <mailto:kowalik@denic.de> <kowalik@denic.de <mailto:kowalik@denic.de>>
>> Sent: Tuesday, June 18, 2024 12:03 PM
>> To: Hollenbeck, Scott <shollenbeck@verisign.com <mailto:shollenbeck@verisign.com>>; regext@ietf.org <mailto:regext@ietf.org>
>> Subject: [EXTERNAL] Re: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-
>> 03
>>
>> Hi Scott,
>>
>> Splitting Section 5 into "Current Practices" and "Proposed experimental
>> Practices" would offer a lot of more clarity in this respect.
>>
>> Also abstract is not mentioning proposed practices:
>>
>> "This document describes best practices to delete domain and host objects
>> that reduce the risk of DNS resolution failure and maintain client-server data
>> consistency."
>>
>> I would change to:
>> "This document describes best current practices as well as proposes new
>> experimental practices to delete domain and host objects that reduce the risk
>> of DNS resolution failure and maintain client-server data consistency.
>>
>> Kind Regards,
>>
>> Pawel
>>
>> On 18.06.24 17:46, Hollenbeck, Scott wrote:
>>> Pawel, the document already describes known practices, their issues, and
>> those that are proposed, along with analysis of how they're thought to be
>> better. What's missing?
>>> Scott
>>>
>>>> -----Original Message-----
>>>> From: kowalik@denic.de <mailto:kowalik@denic.de> <kowalik@denic.de <mailto:kowalik@denic.de>>
>>>> Sent: Tuesday, June 18, 2024 11:36 AM
>>>> To: regext@ietf.org <mailto:regext@ietf.org>
>>>> Subject: [EXTERNAL] [regext] Re: WGLC:
>>>> draft-ietf-regext-epp-delete-bcp-03
>>>>
>>>> Hi,
>>>>
>>>> In the course of the actual discussion on the clarity of documents we
>>>> produce, especially related to implementation maturity of the
>>>> solutions I would need to repeat the remark I brought up during the call for
>> adoption [1].
>>>> I think the document, being a BCP, should be very specific about
>>>> which methods have already been field proven and which are kind of
>>>> experimental with unknown implementation or operational impact.
>>>>
>>>> [1]
>>>> https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG- <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->
>>>>
>> G0Gpki1ow4L_ezX0s3WaHnOjI1vjfr3mJJj49Wx2QArJxHz_7WstL3WUkGvQXd
>>>> O_QI2Mxh_wKKA9UvoWj_UJUlybSsh9WVIQK4h2Hcc-
>>>>
>> LRehJ7_1E2xmP1iH5FpdEdMxrN2CGNIlFnFVDNyoiPSKZ_xANApbBjCnW1gXU
>>>> pEpbFO4TVSXTFbYeTzWmJT3PHkqzw4dmncdVrCbGbV8b99WCfG2c-
>>>>
>> ahrgqfi1TBuravVfcBrC61Q9oNp2QGP5FzDQ9hbP2gAR93uA0CSo/https%3A
>> %2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FlDkYhEak6_JehglG
>>>> -YuqxBpwgrw%2F
>>>>
>>>> Kind Regards,
>>>>
>>>> Pawel
>>>>
>>>> On 03.06.24 16:56, James Galvin wrote:
>>>>> The document editors have indicated that the following document is
>>>>> ready
>>>> for submission to the IESG to be considered for publication as a Best
>>>> Current
>>>> Practice:
>>>>> Best Practices for Deletion of Domain and Host Objects in the
>>>>> Extensible Provisioning Protocol (EPP)
>>>>> https://secure-
>>>> web.cisco.com/1kPqjqwCJfsCxQHvBeBU74pCSqzTWdJQ6jZ6RQm7-
>>>>
>> 2mcVf8pmghWjgEJRqVdkFppbs7M_HiHAE7CVQJzMEmDrBQgrLJGI5WUGwC
>>>> 1rsVWeoAzVgC
>>>>
>> MgBrz_tOOZZ_yWsmaNrvKsCiYCAcKk34iXfGeMuD9YljauXP4IJOs_ATrkUln1aa
>>>> Ezd61l
>>>>
>> pawefS7VAbs77M4BMKMb1NWfX_heCB1wqcD1HYXnSkD203cWebWfQKgj
>>>> 5C8DWHYMuKHwud
>>>>
>> dFtPJJaxGWQA_qb0xjiiL9S3sLb2CbefBMEsC2aAwis4YLx2E/https%3A%2F%2F
>>>> datatr
>>>>> acker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-delete-bcp%2F03%2F
>>>>>
>>>>> Please indicate your support or no objection for the publication of
>>>>> this
>>>> document by replying to this message on list (a simple “+1” is sufficient).
>>>>> If any working group member has questions regarding the publication
>>>>> of this
>>>> document please respond on the list with your concerns by close of
>>>> business everywhere, Monday, 17 June 2024.
>>>>> If there are no objections the document will be submitted to the IESG.
>>>>>
>>>>> The Document Shepherd for this document is Andy Newton.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Antoin and Jim
>>>>> REGEXT WG Co-Chairs
>>>>>
>>>>> _______________________________________________
>>>>> regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email
>>>>> to regext-leave@ietf.org <mailto:regext-leave@ietf.org>
> _______________________________________________
> regext mailing list -- regext@ietf.org <mailto:regext@ietf.org>
> To unsubscribe send an email to regext-leave@ietf.org <mailto:regext-leave@ietf.org>
>
>
>