Re: [Wish] Artart early review of draft-ietf-wish-whip-08

[Sergio Garcia Murillo <[e-mail]>]

And now the big part. As I said previously, most of the text was extracted
from the SCIM registration of the "scim" uri param, which I hope it would
be close enough so I didn't have to deep dive into the IANA process.

On Sun, Jun 11, 2023 at 8:18 PM Barry Leiba via Datatracker <
[e-mail]> wrote:

> Reviewer: Barry Leiba
> Review result: Ready with Issues
>
>
> — 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.
>

I think we want to use just BCP 26 "Specification Required" for allowing
anyone to register a new extension (which could be driven by an open source
community for example) without requiring a full RFC.


>
> It also seems that you only require an RFC in certain circumstances
> (modifying
> things that have already been in RFCs), but that’s unclear.


Not sure exactly how to clarify this, are you referring that it is unclear
why we are asking for an RFC when we already asked for an RFC always (which
we have changed now) or  about clarifying when "things that have already
been in RFCs" mean?


> 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.
>

How should we clarify it? If I understood the process correctly, just the
request to iana and a pointer to specification is required, right?


>
> 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.
>

Do you have any previous examples of this that we can use as reference?


>
> > The registration procedure begins when a completed registration
> > template, defined in the sections below, is sent to
> > [e-mail] and [e-mail].
>
> 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?


I think we should just require the email to iana mailing list and leave
wish email as strongly encouraged. Changed the draft accordingly.


>
> > 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.
>

How should we change the text to reflect that?



>
> > 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...)
>

Added some clarification to the rejection with cause here:
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/ad0dbbde61be1d104909777bc11bd417526df9ae


>
> > 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”.


Changed.
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/e1bd984aa5793ede13859fd36fd74d2791b8b34e


>
>
> 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?
>

Changed
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/b6418c53665422855ee686bf0f3f6e3aa9f375a1


> > 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?
>

Removed


Best regards
Sergio