Murray has specifically asked for a review of the IANA Considerations section, and I have a bunch of comments there.  One general comment first, though:

Throughout the document you refer to both “URI” and “URL”, seemingly interchangably.  I would feel much better if you stuck with “URI” consistently throughout.  For example, in Section 4.4:

> Each STUN/TURN server will be returned using the "Link" header
> field [RFC8288] with a "rel" attribute value of "ice-server".
> The Link target URI is the server URL as defined in [RFC7064]
> and [RFC7065].

But if you look in RFCs 7064 and 7065, there is no ocurrance of “URL” in either; the both say “URI”, and anyone looking in them for “the server URL” will not find it.

Now for the registration stuff...

— Section 6.2 —

> IANA has added an entry to the "IETF URN Sub-namespace for
> Registered Protocol Parameter Identifiers" registry and created
> a sub-namespace for the Registered Parameter Identifier as per
> [RFC3553]: "urn:ietf:params:whip".

IANA has not done that yet.  It should say “IANA is asked to add an entry… and create… .”  The RFC Editor will change the text once that’s been done, but getting it right helps with the bookkeeping.

> To manage this sub-namespace, IANA has created the "WebRTC-HTTP
> ingestion protocol (WHIP) URIs" registry, which is used to
> manage entries within the "urn:ietf:params:whip" namespace.

Similarly here, “IANA is asked to create… which will be used… .”  Also, IANA will ask you about the BCP 26 policy for registrations here.  The later text seems to indicate that the policy should either be listed as “Specification Required” with an indication that the specification MUST be an RFC (but see the discussion of 6.4.1 below), or as “RFC Required AND Expert Review”.  The latter is probably better, I think.  Or maybe it's *just* "Specification Required", and the type of specification is at the judgment of the designated expert based on information given here.  In any case, that should be clearly specified in 6.2.

> * Registry name: WHIP

Well, but above you say that the name is "WebRTC-HTTP ingestion protocol (WHIP) URIs”.  This needs to be consistent, so IANA (as well as other readers) doesn’t think you’re talking about two different registries here (and there's more of this below).

— Section 6.3 —

> This section creates and registers an IETF URN Sub-namespace for
> use in the WHIP specifications and future extensions.

I don’t understand: the first paragraph of 6.2 did that.  It seems to me that this defines the *management* of that sub-namespace, no?

— Section 6.4.1 —

Now comes the “an RFC is REQUIRED” part.  As written, this can mean that *any* of these are acceptable:

- Any IETF-stream RFC, including Standards Track, Experimental, Informational, or BCP, which gets IETF consensus.
- Any IAB-stream RFC, which gets the consensus of the IAB only.
- Any IRTF-stream RFC, which is collectively approved by the Research Group chairs.
- Any Independent-stream RFC, which does not imply any sort of consensus from anyone.

Is that really what you want?  If so, fine.  But if not, you need to specify this more clearly, such as “a Standards-Track or Experimental RFC in the IETF stream”, or whatever.

It also seems that you only require an RFC in certain circumstances (modifying things that have already been in RFCs), but that’s unclear.  It would be good to be clear whether any documentation beyond what’s in the registration request is necessary otherwise, or whether the request to the mailing list or IANA is sufficient.  Please be explicit now to avoid problems later… and also consider that flexibility is often better than rigidity, which you might regret later.

Resolving that comment will also resolve the issue in the template in 6.4.2, where “Reference: A formal reference to the publicly available specification” is not clear about what “publicly available specification” we’re talking about.

This also needs some guidance for the designated expert — assume that eventually there will be a DE who was not around when this was written.  What should be DE be looking for?  What reasons might there be to “reject with cause”?  What documentation will the DE be relying on?  What judgment will the DE be applying?  It doesn't have to be incredibly detailed, but there should be some reasonable guidance.

> The registration procedure begins when a completed registration
> template, defined in the sections below, is sent to
> wish@ietf.org and iana@iana.org.

Earlier you say, “Use of the mailing list is strongly encouraged,” but here it seems required, as it’s how the registration process starts.  Which is it?

> Within two weeks, the designated expert is expected to tell IANA
> and the submitter of the registration whether the registration
> is approved, approved with minor changes, or rejected with
> cause.

Normally, the expert communicates with IANA and IANA informs the requester and tracks the process.  Unless there’s a very good reason to vary for this case, I strongly recommend that you let IANA handle this through its normal process, and that you consult Amanda if necessary to understand how their normal process works.  Remember that they do a lot of these.

> When a registration is rejected with cause, it can be resubmitted
> if the concerns listed in the cause are addressed.

I also think you should be clear that “rejected with cause” will happen only when the discussion on the mailing list gets deadlocked… that is, that the DE, the requester, and any others involved in the discussion are expected to use the mailing list to work out the issues, minor or major, and only when that fails do we give up and reject the request outright.  (Of course, in that case it seems unlikely that the requester will then turn around and address the issues, but, well...)

> Decisions made by the designated expert can be appealed to the
> IESG Applications Area Director, then to the IESG.

There is no “IESG Applications Area Director”.  There is an “ART Area Director”, or it can be spelled out as “Applications and Real-Time Area Director”.

> Once the registration procedure concludes successfully, IANA
> creates or modifies the corresponding record in the WHIP
> Protocol Extension registry.

I see no “WHIP Protocol Extension registry” here.  It’s called “WebRTC-HTTP ingestion protocol (WHIP) URIs,” yes?  Or is there another registry that I’m missing?

> The completed registration template is discarded.

Why?  IANA generally keeps them for their records, and often makes them available as part of the registry.  Is there a particular reason to discard them?  Actually, in this case it seems that the entire template will *be* the registry entry, no?

— Section 6.4.2 —

> Description: A short phrase describing the function of the extension

I suspect “short phrase” is not adequate, and we’ll just wind up with a repetition of the “Name”, as perhaps, “Name: Farble bender; Description: Bends the farble”.  I would say, “A brief description of the function of the extension, in a short paragraph or two.”

-- 
Barry