[regext] Re: normative language and references in draft-ietf-regext-delete-bcp

["Andrew Newton (andy)" <[e-mail]>]

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 <[e-mail]> 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: [e-mail] <[e-mail]>
> >> Sent: Thursday, September 19, 2024 9:47 AM
> >> To: Hollenbeck, Scott <[e-mail]>; [e-mail]
> >> 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: [e-mail] <[e-mail]>
> >>>> Sent: Thursday, September 12, 2024 2:29 AM
> >>>> To: Hollenbeck, Scott <[e-mail]>
> >>>> 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]