MIME-Version: 1.0
References: <90b13eb0-0269-4e4a-a3bf-b82dc54e79f3@hxr.us>
 <c3decf58f1f04e47a47ab1f8b32d5d4a@verisign.com>
 <d697e4ce-9cec-4231-bd71-7ce3de602581@hxr.us>
 <ca771eb844344503a52ac3e1d036b606@verisign.com>
 <91905f6d53cb4f29978eefccb8f0889f@verisign.com>
 <c58d31fd-cff5-4998-b009-36b1e0a201f3@denic.de>
 <fe8d7c5f022046918b8238ddd8234f8d@verisign.com>
 <3b7ae504-fbf1-4f23-b1be-297dd5ad6543@denic.de>
 <93931fca85334496b2d74bcd6cd3ee26@verisign.com>
 <D10F8F1A-B1F2-4DC8-9A5E-592858A9C6AC@elistx.com>
In-Reply-To: <D10F8F1A-B1F2-4DC8-9A5E-592858A9C6AC@elistx.com>
From: "Andrew Newton (andy)" <andy@hxr.us>
Date: Thu, 17 Oct 2024 14:09:31 -0400
Message-ID: 
 <CAAQiQRe4nVoLFytjMRqwGbRVHTz7E9q_n_TpmSvEc11eNr5d-A@mail.gmail.com>
To: James Galvin <galvin@elistx.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: PX7RP76FOMPE2OMSUPES2BA4R73I7RDN
CC: regext@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bregext=5D_Re=3A_normative_language_and_references_in_draft-ietf?=
	=?utf-8?q?-regext-delete-bcp?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/regext/-EfkQ38T3AaqLLXOgrRDenjLvtw>

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/mcMbVUspJuALOHWAGQWeuoxAy=
YM/

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=E2=80=AFPM James Galvin <galvin@elistx.com> wr=
ote:
>
> Speaking as co-Chair, here is where I believe this discussion has landed.
>
> From a consensus point of view, I=E2=80=99m declaring the working group c=
onsensus to be that v08 of draft-ietf-regext-delete-bcp is ready for submis=
sion to the IESG.  We=E2=80=99ve been through WGLC and we=E2=80=99ve had qu=
ite some discussion since then but I do not believe the changes have been m=
aterial 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=
=E2=80=99ve been fortunate that we typically have full consensus amongst th=
ose who speak up regarding a document=E2=80=99s status.  The Chairs are sen=
sitive to alternate points of view when the number of those who engage is f=
requently small.
>
> The Chair=E2=80=99s suggestion is to acknowledge the point of view in the=
 Shepherd Writeup.  We think it=E2=80=99s important so that if questions ar=
ise 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 documen=
t 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 t=
o the IESG for publication as a Best Current Practice.
>
> Thanks to all for your passionate and detailed discussion of the question=
s.  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: kowalik@denic.de <kowalik@denic.de>
> >> Sent: Thursday, September 19, 2024 9:47 AM
> >> To: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
> >> Subject: [EXTERNAL] Re: [regext] FW: Re: normative language and refere=
nces
> >> in draft-ietf-regext-delete-bcp
> >>
> >> Hi Scott,
> >>
> >> On 12.09.24 14:39, Hollenbeck, Scott wrote:
> >>>> -----Original Message-----
> >>>> From: kowalik@denic.de <kowalik@denic.de>
> >>>> Sent: Thursday, September 12, 2024 2:29 AM
> >>>> To: Hollenbeck, Scott <shollenbeck@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 th=
read
> >> [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 Sectio=
n 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  actuall=
y required
> >> for interoperation or to limit behavior which has  potential for causi=
ng harm
> >> (e.g., limiting retransmisssions)"
> >>>
> >>> "or to limit behavior which has  potential for causing harm". The gui=
dance
> >> 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 ex=
pect some
> >> normative language here to be able to follow the recommendation of Sec=
tion
> >> 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 w=
e 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 Obj=
ect 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-leave@ietf.org
>
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-leave@ietf.org