Hi Pawel,
Thank you for your close reading of the doc! We felt that adding a "practices
to avoid" to each observed/not-observed section was unnecessary with the best
practices already specified. Would you prefer the addition of a "This practice
MUST NOT be used" sentence for the worst practices? I think those would include
"5.1.3.1. Renaming to External, Presumed Non-Existent Hosts", "5.1.3.3.
Renaming to Non-Authoritative Hosts", and "5.1.4.1. Renaming to Pseudo-TLD".
As to the explicit delete, I think the previous "observed in use" was an
incorrect reading of a list email from Gavin Brown about observed practices.
For explicit delete, we had in mind that a client would provide an explicit
flag specifying that the client wants to delete any host objects belonging to
another client ("They would be required to explicitly request deletion of these
objects."). As far as we know, no one is currently operating with that
practice. I will edit to try to make that clearer, which may make "5.2.2.1.3.1.
Explicit Deletion Request" redundant.
Thanks,
Bill
On 6/24/24, 6:10 AM, "kowa...@denic.de <mailto:kowa...@denic.de>"
<kowa...@denic.de <mailto:kowa...@denic.de>> wrote:
Hi Bill,
Yes, this version makes it clear which methods are current and which
proposed. Thanks. I see you didn't decide to keep the category of
"practices to avoid" from "00" draft. Is there a reason? It was
conveying an important message which ist not that directly stated from
the current document.
As the document now has a bit of more nested structure please consider
increasing tocdepth, otherwise Table of Content does not offer clear
overview of the methods and the document structure. It took me a while
to figure out that 5.2.2.1. Allow Explicit Delete of Host Objects has a
full own list of extension methods in 5.2.2.1.3. which make yet another
ToC level.
I noticed "Allow Explicit Delete of Host Objects" turned from "observed
in use" to "not observed in use". Is is an intended change?
I'd also need small clarification. The difference between 5.2.1.1.
Delete Affected Host Objects and 5.2.2.1. Allow Explicit Delete of Host
Objects. The descriptions are very similar and in the first one the
registry would automatically disassociate the deleted host objects from
domain objects sponsored by other clients and in the latter it would be
done by the client. Is the description correctly saying that the
difference is about who is doing die disassociation? How would client
disassociate a host object from a domain sponsored by other client? It
wouldn't be an update on domain object, would it?
Or are these two methods actually about deleting the domain object and
in case of 5.2.1.1. the server implicitly cascading the delete to
subordinate host objects resulting in disassociation, and in 5.2.2.1.
allowing and requiring the client to explicitly delete those subordinate
host objects before deleting the domain?
Understanding that difference would also help me to determine, whether
methods listed in 5.2.2.1.3 actually may apply to both those cases or
only the second one as the document is structured now with this secion
being nested under 5.2.2.1.
Kind Regards,
Pawel
On 21.06.24 19:09, Carroll, William wrote:
> Pawel,
> I've uploaded a version 04 of the doc with the practices organized into
> observed and potential subsections. We didn't want multiple listings of best
> current practices in both sections 5 and 6. Hopefully this version is clear
> enough.
> Thanks!
> Bill
>
> On 6/19/24, 6:37 AM, "kowa...@denic.de <mailto:kowa...@denic.de>
> <mailto:kowa...@denic.de <mailto:kowa...@denic.de>>" <kowa...@denic.de
> <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
> <mailto:kowa...@denic.de>>> wrote:
>
>
> 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....@dmarc.ietf.org
>> <mailto:40verisign....@dmarc.ietf.org> <mailto:40verisign....@dmarc.ietf.org
>> <mailto:40verisign....@dmarc.ietf.org>>
>> <mailto:40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org>
>> <mailto:40verisign....@dmarc.ietf.org
>> <mailto:40verisign....@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: kowa...@denic.de <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
>>> <mailto:kowa...@denic.de>> <mailto:kowa...@denic.de
>>> <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
>>> <mailto:kowa...@denic.de>>> <kowa...@denic.de <mailto:kowa...@denic.de>
>>> <mailto:kowa...@denic.de <mailto:kowa...@denic.de>>
>>> <mailto:kowa...@denic.de <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
>>> <mailto:kowa...@denic.de>>>>
>>> Sent: Tuesday, June 18, 2024 12:03 PM
>>> To: Hollenbeck, Scott <shollenb...@verisign.com
>>> <mailto:shollenb...@verisign.com> <mailto:shollenb...@verisign.com
>>> <mailto:shollenb...@verisign.com>> <mailto:shollenb...@verisign.com
>>> <mailto:shollenb...@verisign.com> <mailto:shollenb...@verisign.com
>>> <mailto:shollenb...@verisign.com>>>>; regext@ietf.org
>>> <mailto:regext@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>>
>>> <mailto:regext@ietf.org <mailto:regext@ietf.org> <mailto: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: kowa...@denic.de <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
>>>>> <mailto:kowa...@denic.de>> <mailto:kowa...@denic.de
>>>>> <mailto:kowa...@denic.de> <mailto:kowa...@denic.de
>>>>> <mailto:kowa...@denic.de>>> <kowa...@denic.de <mailto:kowa...@denic.de>
>>>>> <mailto:kowa...@denic.de <mailto:kowa...@denic.de>>
>>>>> <mailto:kowa...@denic.de <mailto:kowa...@denic.de>
>>>>> <mailto:kowa...@denic.de <mailto:kowa...@denic.de>>>>
>>>>> Sent: Tuesday, June 18, 2024 11:36 AM
>>>>> To: regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org
>>>>> <mailto:regext@ietf.org>> <mailto:regext@ietf.org
>>>>> <mailto:regext@ietf.org> <mailto: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->
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->>
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->>
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG->>
>>>>> <https://secure-web.cisco.com/1WmRFtKB8RXzAHuXHoN-OpHA3vOlG-&gt;>>
>>>>>
>>> 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>
>>>>>> <mailto:regext@ietf.org <mailto:regext@ietf.org>>
>>>>>> <mailto:regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org
>>>>>> <mailto:regext@ietf.org>>> To unsubscribe send an email
>>>>>> to regext-le...@ietf.org <mailto:regext-le...@ietf.org>
>>>>>> <mailto:regext-le...@ietf.org <mailto:regext-le...@ietf.org>>
>>>>>> <mailto:regext-le...@ietf.org <mailto:regext-le...@ietf.org>
>>>>>> <mailto:regext-le...@ietf.org <mailto:regext-le...@ietf.org>>>
>> _______________________________________________
>> regext mailing list -- regext@ietf.org <mailto:regext@ietf.org>
>> <mailto:regext@ietf.org <mailto:regext@ietf.org>> <mailto:regext@ietf.org
>> <mailto:regext@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>>>
>> To unsubscribe send an email to regext-le...@ietf.org
>> <mailto:regext-le...@ietf.org> <mailto:regext-le...@ietf.org
>> <mailto:regext-le...@ietf.org>> <mailto:regext-le...@ietf.org
>> <mailto:regext-le...@ietf.org> <mailto:regext-le...@ietf.org
>> <mailto:regext-le...@ietf.org>>>
>>
>>
>>
>
>
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
