Guidelines and Registration Procedures for New URI Schemes
draft-hansen-2717bis-2718bis-uri-guidelines-07

[Ballot discuss]
The Abstract needs to indicate that this document obsoletes both
  RFC 2717 and RFC 2718.

  Section 1 says:
  >
  > o  discourage multiple definitions of URI scheme names for different
  >    purposes;
  >
  I think we want different names for different purposes.  I think it
  ought to say something like:
  >
  > o  discourage multiple definitions of URI scheme names for the same
  >    purpose;

[Ballot discuss]
These are questions; I want them answered but it may well be that no
document changes are required.

1) Previous versions of this document seemed to allow multiple
provisional registrations of the same name.  The procedures in section
5 do not allow this any more.  Is that intended?

2) Section 5.3 requires iesg approval to move a provisional
registration to permanent.  However a new permanent registration does not require IESG approval.

3) I want to confirm that the idea that permanent registrations should
be strongly encouraged to be standards track has been dropped.  I'm
fine with that but just wanted to confirm my understanding.

[Ballot discuss]
The Abstract needs to indicate that this document obsoletes both
  RFC 2717 and RFC 2718.

  Section 1 says:
  >
  > o  discourage multiple definitions of URI scheme names for different
  >    purposes;
  >
  I think we want different names for different purposes.  I think it
  ought to say something like:
  >
  > o  discourage multiple definitions of URI scheme names for the same
  >    purpose;

[Ballot comment]
Typo noted by Spencer Dawkins

> Eek! This is a typo. The second 'provisional' should be 'permanent'.
> It's trying to say that IANA should do what the Expert
> recommends.
>
>
>>I had reviewed version 05 of this draft and chatted with the authors on a
>>couple of points, so "no objection to publication as a BCP",
>>but there's one incoherent part, at the top of page 10:
>>
>>  5.  If Expert Review recommends registration 'provisional' or
>>      'provisional' registration, IANA adds the registration to the
>>      appropriate registry.

IDNits mentions an extra space in the title on page 1.

I'm not sure if it's a good idea to include RFCs 2717 and 2718 as normative references if they're being obsoleted.  Informative makes more sense to me.  Why do they need to be normative?

Section 5.2, list item 3: I vaguely recall Leslie Daigle having an issue with using a W3C mailing list for review of IETF-managed registration requests.  I'll check with her to be sure, but we can talk about this during the last call.