This is done. In addition, I noted the informative reference to RFC 3915 has changed to normative.
However, during my review of the traffic on this list, it appears there was a tacit agreement on changing some of the normative language. See: https://mailarchive.ietf.org/arch/msg/regext/mcMbVUspJuALOHWAGQWeuoxAyYM/ If this draft is revised with such a change before moving to the AD, I will need to revise the write-up as well. -andy On Tue, Oct 15, 2024 at 8:19 PM James Galvin <gal...@elistx.com> wrote: > > 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: kowa...@denic.de <kowa...@denic.de> > >> Sent: Thursday, September 19, 2024 9:47 AM > >> To: Hollenbeck, Scott <shollenb...@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: kowa...@denic.de <kowa...@denic.de> > >>>> Sent: Thursday, September 12, 2024 2:29 AM > >>>> To: Hollenbeck, Scott <shollenb...@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-le...@ietf.org > > _______________________________________________ > 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
