> -----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
