Received changes through RFC Editor sync (created alias RFC 8958, changed title to 'Updated Registration Rules for URI.ARPA', changed abstract to 'This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone.', changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2020-12-02, changed IESG state to RFC Published, created updates relation between draft-hardie-dispatch-rfc3405-update and RFC 3405)

[Ballot comment]
It seems the comment from the Gen-ART review was not addressed:

"1.  Introduction

  Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405
  [RFC3405], describes the registration procedures for assignments in
  URI.ARPA.  The document requires that registrations be in the "IETF
  tree" of URI registrations.  The use of URI scheme name trees was
  defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
  Since the use of trees was discontinued, there is no way in the
  current process set out in BCP 35 [RFC7595] to meet the requirement."

This is indeed a nit, but I'd prefer s/the requirement/the above requirement/.
The current text did make me briefly think "Which requirement?".

[Ballot comment]
Section 1

I suggest mentioning somehow in the prose that RFC 4395 was obsoleted by
RFC 7595, to establish the last link in the chain leading to "the
current process"; in the current form the RFC 7595 reference seems to
lack any preceding motivation.

(I also agree with the Gen-ART reviewer that spelling out "the
requirement" more explicitly would be helpful; that suggestion seems to
have gotten lost in the ensuing thread.)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-hardie-dispatch-rfc3405-update-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

IANA understands that the rules for registration in the .uri.arpa zone were established by RFC3405. That document says:

"In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree. The requirements for this tree are specified in BCP35."

IANA understands that [ RFC-to-be ] removes this normative requirement and that the new requirement is:

"All registrations in URI.ARPA MUST now be for schemes which are permanent registrations, as they are described in BCP 35."

On the .ARPA Zone Management page located at:

https://www.iana.org/domains/arpa

IANA Question --> RFC3405 is listed as the reference for the .uri.arpa zone. Upon approval of this document, should this reference be replaced with [ RFC-to-be ] or should this document be added as an additional reference?

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-24):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: barryleiba@gmail.com, draft-hardie-dispatch-rfc3405-update@ietf.org, dispatch@ietf.org, spencerdawkins.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-hardie-dispatch-rfc3405-update-03.txt> (Updated registration rules for URI.ARPA) to Best Current Practice


The IESG has received a request from an individual submitter to consider the
following document: - 'Updated registration rules for URI.ARPA'
  <draft-hardie-dispatch-rfc3405-update-03.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 3405 by removing references to the IETF
  tree from the procedures for requesting that a URI scheme be inserted
  into the uri.arpa zone.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/



No IPR declarations have been submitted directly on this I-D.

1. Summary:

  The document shepherd is Spencer Dawkins. The responsible Area Director is Barry Leiba.

  This document removes the normative requirement from RFC 3405 for
  registrations in URI.ARPA to be from the IETF URI Tree.

  This document will be published as a Best Current Practice, since it updates BCP 35.

2. Review and Consensus

  This draft was Dispatched at IETF 108, to be AD sponsored, and Barry Leiba agreed
  to sponsor it. The conversation in Dispatch was broadly supportive, although
  Dispatch did not adopt the draft or call for working group consensus on it, so it will
  receive a four-week IETF Last Call as per BCP 9.

3. Intellectual Property

  The author has confirmed that he knows of no IPR that applies to this draft.

4. Other Points

  ID Nits reports a few informational references to obsoleted RFCs:

  -- Obsolete informational reference (is this intentional?): RFC 2717
    (Obsoleted by RFC 4395)

  -- Obsolete informational reference (is this intentional?): RFC 4395
    (Obsoleted by RFC 7595)

  Both of these references are intentional, because the draft is referencing
  the RFCs that got us into the current situation.

1. Summary:

  The document shepherd is Spencer Dawkins. The responsible Area Director is Barry Leiba.

  This document removes the normative requirement from RFC 3405 for
  registrations in URI.ARPA to be from the IETF URI Tree.

  This document will be published as a Best Current Practice, since it updates BCP 35.

2. Review and Consensus

  This draft was Dispatched at IETF 108, to be AD sponsored, and Barry Leiba agreed
  to sponsor it. The conversation in Dispatch was broadly supportive, although
  Dispatch did not adopt the draft or call for consensus on it, and it will receive
  a four-week IETF Last Call as per BCP 9.

3. Intellectual Property

  The author has confirmed that he knows of no IPR that applies to this draft.

4. Other Points

  ID Nits reports some things that should be cleared up before Last Call. The
  shepherd will work these details with the author.