On 03-Sep-20 05:41, Ted Hardie wrote: > To reply to the text change in particular: > > On Wed, Sep 2, 2020 at 3:52 AM Timothy Mcsweeney <tim@xxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxx>> wrote: > > __ > > >>This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text.. > > And it should. There is no legitimate reason not to. > > > > > You would prefer changing this: > > 2. Updated Requirements > > This document removes the normative requirement from RFC 3405 for > registrations in URI.ARPA to be from the IETF URI Tree. > > All registrations in URI.ARPA MUST now be for schemes which are > permanent registrations, as they are described in BCP 35. > > to something like this: > > 2. Updated section 3.1.1 for RFC 3405 > > The following text replaces section 3.1.1 of RFC 3405: > > 3.1.1 Only permanent URI registrations allowed. > > All schemes registered in URI.ARPA MUST be schemes which are > permanent registrations, as they are described in BCP 35. > > Is that right? Re-assuming my hat as a Gen-ART reviewer for this draft, I think that this change would be a mistake, as it no longer explicitly informs the reader what has been changed in RFC 3405. If we really want to be precise, I suggest: 2. Updated Requirements This document removes the normative requirement from section 3.1.1 of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. All registrations in URI.ARPA MUST now be for schemes which are permanent registrations, as they are described in BCP 35. Regards Brian > > regards, > > Ted Hardie > > >>... seems equivalent and unambiguous to me. > > No surprise here. Maybe the IESG isn't a good fit for you. As a matter of fact, if I were Barry I would drop sponsorship of this draft for all the reasons above. > > > > > > > > >> On 09/02/2020 1:49 AM Murray S. Kucherawy <superuser@xxxxxxxxx <mailto:superuser@xxxxxxxxx>> wrote: >> >> >> On Tue, Sep 1, 2020 at 8:58 AM Timothy Mcsweeney <tim@xxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxx>> wrote: >> >> >While it's certainly possible to add such guidance now, this update is >> >> >very narrowly targeted to fix a serious problem, and I would not want >> >debate about additional text to get in the way of that. >> >> And doesn't using this draft as an update of the entire IANA considerations section effectively remove any means of registration through the mailing lists provided in that same section?? >> >> >> This draft doesn't replace the entire IANA Considerations section of RFC 3405, but rather amends it. That is, after this is published, to get the full IANA Considerations for BCP 65, you would read RFC 3405 and then apply this document as a sort of "patch". That's what we mean when we say "RFC Y updates RFC X", which will be the end result here. >> >> The specific effect of this document when published is to amend Section 3.1.1 of RFC 3405 such that instead of saying "registered under the IETF URI tree", it becomes "a registered permanent URI scheme", and then take "tree" out of the next sentence, and rename the section to something more appropriate. This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text, but it's such a small change that what's here seems equivalent and unambiguous to me. >> >> -MSK >> -- last-call mailing list last-call@xxxxxxxx <mailto:last-call@xxxxxxxx> https://www.ietf.org/mailman/listinfo/last-call > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
