Early Review of draft-ietf-wish-whip-08
review-ietf-wish-whip-08-artart-early-leiba-2023-06-11-00

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