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: kowa...@denic.de <kowa...@denic.de> > Sent: Tuesday, June 18, 2024 12:03 PM > To: Hollenbeck, Scott <shollenb...@verisign.com>; 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: kowa...@denic.de <kowa...@denic.de> > >> Sent: Tuesday, June 18, 2024 11:36 AM > >> To: 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- > >> > 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 To unsubscribe send an email > >>> to regext-le...@ietf.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
