Subject: [quicwg/base-drafts] Allow provisional registrations for all registries (#3170)

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 23:45:31 -0700

This overhauls the system for IANA registries to use a unified scheme that allows provisional registration.  This seems pretty complicated in terms of nailing down all the corner cases, but it is fairly simple in practice:

* Provisional registration is easy, it only requires that the requester provide contact information and (ideally) the codepoint they want. They could provide more, but at their discretion.

* Permanent registration requires that you fill out the fields. 

Experts are required for both, but only really to prevent spam.  We have a few more requirements for permanent registrations of frame types, but that is more for the purposes of advice, because sending an new frame leads to protocol errors if you haven&#39;t agreed to that in the past.

I&#39;ve sketched out a strawman for a codepoint reclamation process.  That advises that experts try to find some use of the codepoint.  There is a date on registrations that can guide the selection of codepoints to reclaim, but these can be updated any time by anyone who wants to keep the registration &quot;live&quot;.

I wanted to sketch this out for transport first, but I intend to update this PR with changes to the HTTP draft if these policies are agreeable.

Closes #3109. Closes #3020.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3170

-- Commit Summary --

  * Allow provisional registrations for all registries

-- File Changes --

    M draft-ietf-quic-transport.md (226)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3170.patch
https://github.com/quicwg/base-drafts/pull/3170.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Oct 2019 00:31:33 -0700

Could contact information be replaced with a domain name. There is much abuse of contact information and domain names can have private contact information? Also, maintaining an email address is harder over time. I realize the field contact field doesn't say email, but that is sort of implied.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#issuecomment-547772289

---

From: hardie <[email-masked]>
Date: Wed, 30 Oct 2019 09:52:54 -0700

On Wed, Oct 30, 2019 at 12:31 AM MikkelFJ <[email-masked]> wrote:

> Could contact information be replaced with a domain name. There is much
> abuse of contact information and domain names can have private contact
> information?
>
You can specify this so that IANA collects the information and thus can
follow up if needed, but where the registry does not display this
information.   I understand that the authors of RFC 8126 are working on a
bis that will make this much more common, if not the default.

> Also, maintaining an email address is harder over time. I realize the
> field contact field doesn't say email, but that is sort of implied.
>
You can also split the contact information from the change controller, if
you want to have, say Joe be the contact but Example Corp be the change
controller.  There's also a presumption that if the change controller is
gone that the change controller for the entire registry (usually the IESG)
can make a determination of what to do in the case that a change is needed.
For many registries this amounts to "do nothing" since there is no scarcity
of code points.  In the case of scarcity, that's how you get re-use when
the change controllers are gone.

Ted

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/3170?email_source=notifications&email_token=AAKVXZGW4DLXVXEZDME5SHLQREZ5BA5CNFSM4JGUI6W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTFPAI#issuecomment-547772289>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAKVXZDFDTCYMGMTNCEWAPDQREZ5BANCNFSM4JGUI6WQ>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#issuecomment-548005590

---

From: David Schinazi <[email-masked]>
Date: Wed, 30 Oct 2019 14:16:21 -0700

DavidSchinazi commented on this pull request.

> +accurate representation of any deployed usage.
+
+
+### Permanent Registrations {#iana-permanent}
+
+Permanent registrations in QUIC registries require Specification Required policy
+{{!RFC8126}}, unless otherwise specified.  The designated expert(s) verify that
+a specification exists and is readily accessible.  Expert(s) are encouraged to
+be biased towards approving registrations unless they are abusive, frivolous, or
+actively harmful (not merely aesthetically displeasing, or architecturally
+dubious).  The creation of a registry MAY specify additional constraints on
+permanent registrations.
+
+The creation of a registries MAY identify a range of codepoints where
+registrations are governed by a different registration policy.  For instance,
+the registries for 62-bit codepoints in this document have stricted policies for

typo: stricter

> +Permanent registrations in QUIC registries require Specification Required policy
+{{!RFC8126}}, unless otherwise specified.  The designated expert(s) verify that
+a specification exists and is readily accessible.  Expert(s) are encouraged to
+be biased towards approving registrations unless they are abusive, frivolous, or
+actively harmful (not merely aesthetically displeasing, or architecturally
+dubious).  The creation of a registry MAY specify additional constraints on
+permanent registrations.
+
+The creation of a registries MAY identify a range of codepoints where
+registrations are governed by a different registration policy.  For instance,
+the registries for 62-bit codepoints in this document have stricted policies for
+codepoints in the range from 0 to 63.
+
+Any stricter requirements for permanent registrations do not prevent provisional
+registrations for affected codepoints.  For instance, a provisional registration
+for a frame type {{iana-frames}} of 61 could be requested.

I think this example contradicts these two statements from this PR?

> The "QUIC Frame Types" registry [...] values between 0x00 and 0x3f are assigned using Standards Action or IESG Approval.

> Provisional registrations require Expert Review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#pullrequestreview-309521923

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 16:26:59 -0700

martinthomson commented on this pull request.

You clipped the key piece of the first quote:

> Permanent registrations in this registry are assigned using [...] except for values between 0x00 and 0x3f [...] which are assigned using Standards Action or IESG Approval [...]

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#discussion_r340903750

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 16:27:30 -0700

@martinthomson pushed 1 commit.

fea8629b7991150a51b86eff18bd302ed633630a  enstricted

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170/files/54ed6dc0572c3b88f05c8eaa8ef5b520eb00dc21..fea8629b7991150a51b86eff18bd302ed633630a

---

From: David Schinazi <[email-masked]>
Date: Wed, 30 Oct 2019 16:48:24 -0700

Ah, thanks for clarifying.

If we decide to allow provisional in [0, 63], then we should add text explaining how the Expert Reviewer should handle those requests, because (unless I missed another sentence) it sounds like they're currently instructed to grant all values except for the first unassigned value. I worry that [0, 63] will fill up pretty quickly if we allow provisional use.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#discussion_r340908927

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 17:06:06 -0700

I share that worry, but I'm trying to let those go.  The main pressure here is that if things start filling up, then we start ejecting registrations sooner.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3170#discussion_r340912995