Original text:
Section 16 of QUIC.  The context ID value of 0 is reserved for UDP payloads, while non-zero values are dynamically allocated: non-zero even-numbered context IDs are client-allocated, and odd-numbered <del> context IDs are server-allocated.  Implementations will provide a context ID allocation service.  That service will allow extensions to request a unique context ID that they can subsequently use for their own purposes.  This means that an HTTP client implementation of the context ID allocation service MUST only provide even-numbered IDs, while a server implementation MUST only provide odd-numbered IDs. The context allocation service MUST NOT return the same context ID twice, however it MAY return IDs in any order.  Once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. Additionally, note that the context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics. </del>  Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does

Reviewer comments:
Can you elaborate on what the motivation for this is? Introducing the "context ID allocation service" concept means that extensions can conveniently say "Then request a context ID from the allocation service and doo foo with it". If we remove this text, it'll make extension specs harder to write.
Occam's Razor. It's unnecessary complication that makes this text harder to read. I don't agree. The job of the specification is to document external behavior. I don't agree that it makes future specs more difficult. They can just say "allocate a context ID". It's an internal detail of the implementation that there is a context ID allocation service.
How about the following? It removes the concept but keeps the requirements we need.
I prefer removing the allocation service as a concept and specifying the requirements. I did find this a bit confusing in David's proposed text I think the point is clear already and the rationale is not required. Maybe remove this clause?
This text still has the problem that it first says you can allocate each context ID once and then later it says actually you can allocate it once per namespace. Why not say this upfront as in my PR?
My apologies NAME I think I had missed the added sentence in the middle when looking at this the first time. This LGTM modulo removal of the optional sentence at the end.

Revised text:
Section 16 of QUIC.  The context ID value of 0 is reserved for UDP payloads, while non-zero values are dynamically allocated: non-zero even-numbered context IDs are client-allocated, and odd-numbered  <ins> context IDs are server-allocated.  The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics.  Context IDs must not be re-allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does