From nobody Thu Jun 29 02:19:59 2023 Return-Path: X-Original-To: wish@ietfa.amsl.com Delivered-To: wish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3CC151080; Thu, 29 Jun 2023 02:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh63zWaNU2Km; Thu, 29 Jun 2023 02:19:52 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C1CC14CF1B; Thu, 29 Jun 2023 02:19:52 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-98de21518fbso57094466b.0; Thu, 29 Jun 2023 02:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688030391; x=1690622391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jCQaBvEdXCP7d0Uaq1NKCV65wiiMgXhPz6HcgVeUy7o=; b=NQHc4vj4lrvzXgnhJlqQhW5dWvxucA17tNJiRSMcQsWH0tklO5fU5luiZc6Oyh7DDZ IgjGXFoVhpswnE4PupxujecL1FAfIoJTFjFWrN12+qp5Z0gDGVVqmzXtFW3SprXRLDHR Ir5ZrM7k1C4HJQHBqpeTRFcDLRP5mUpPtbMua9KGomrKr8ssf+VrCe/6LjyqgwBov5HW M0mA1Dif+Ho7dVvV2vHH6hQJ4MScbbLAiURf4etE+arfMKtmFeROYnn1zqGtrwWzLqMS uxGbFy9K19cz4oUkkJCb2nyc0jS3umSX4K2yp/mfgWVWYeJXkqo+uYlQjCHAiUCiDUZB sZ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688030391; x=1690622391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jCQaBvEdXCP7d0Uaq1NKCV65wiiMgXhPz6HcgVeUy7o=; b=Sc6udTj6Gu2QlExGJJSkO6O8cEUU0c0VfUILNGeVMY8O4z/DgjmtWbDYiBDHUFiOiv zNFwDtRzs+e39Ubsdr1wPhaL45hIU3IiXCm/ZFO9emP8NGZ/40uu5oPkAC/3rXo6Dwjw vetJptCWE/3zn4Vr8hQXVaseO372jRj3QbKOuORWU89ItaGqovjhJtUrYzFZ4RvdZHdy QNLkz23THZHiCb2A3C3mgjjrkKAIFOtOa1o59AC0qvChSJg4ZxkD8WYJlNSTJAAuIO3f wClZBtJ2k2VwObnZC8qGyx0ejlmlc9a/zHUqm9VZXgxHMZVU1v4B2m3gqqlbRRgjzmp+ JblA== X-Gm-Message-State: AC+VfDxQ7+bla7PPw6FGJv0dlk8aG8IyvKVyrUdZaG8Stz72xUP/iY0h ZrGxtinl8KgMWImzo9KNRDRty6/aZIN+elZVGPCxFoHDQwY= X-Google-Smtp-Source: ACHHUZ6WBhKgtEsT0UIZFKaeMNx7CJCV+jGY4q9wpCMDIIRXHHo4KIoWXikNIicN96p8b5yz9rHpZUyMqPWqzm11e98= X-Received: by 2002:a17:907:3eaa:b0:992:bc8:58d8 with SMTP id hs42-20020a1709073eaa00b009920bc858d8mr7676490ejc.6.1688030390902; Thu, 29 Jun 2023 02:19:50 -0700 (PDT) MIME-Version: 1.0 References: <168650749719.62197.6608203180443233736@ietfa.amsl.com> In-Reply-To: <168650749719.62197.6608203180443233736@ietfa.amsl.com> From: Sergio Garcia Murillo Date: Thu, 29 Jun 2023 11:19:39 +0200 Message-ID: To: Barry Leiba Cc: art@ietf.org, draft-ietf-wish-whip.all@ietf.org, wish@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1e27d05ff413329" Archived-At: Subject: Re: [Wish] Artart early review of draft-ietf-wish-whip-08 X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2023 09:19:56 -0000 --000000000000d1e27d05ff413329 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Barry, Thank you very much for your review, I have fixed some of the issues you raised in your review, but I would need some feedback for the main ones regarding IANA registration. I will address that in a different email so we can discuss it easily by email On Sun, Jun 11, 2023 at 8:18=E2=80=AFPM Barry Leiba via Datatracker < noreply@ietf.org> wrote: > 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 =E2=80=9CURI=E2=80=9D and =E2= =80=9CURL=E2=80=9D, seemingly > interchangably. I would feel much better if you stuck with =E2=80=9CURI= =E2=80=9D > 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 =E2=80=9C= URL=E2=80=9D in > either; the both say =E2=80=9CURI=E2=80=9D, and anyone looking in them fo= r =E2=80=9Cthe server URL=E2=80=9D > will not find it. > Changed to URI as per your review: https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/cacdd61ea2d3b= e1e99fae9c280529d44742eaedc > > Now for the registration stuff... > > =E2=80=94 Section 6.2 =E2=80=94 > > > 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 =E2=80=9CIANA is asked to add = an entry=E2=80=A6 > and > create=E2=80=A6 .=E2=80=9D The RFC Editor will change the text once that= =E2=80=99s 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, =E2=80=9CIANA is asked to create=E2=80=A6 which will be u= sed=E2=80=A6 .=E2=80=9D Done: https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/1632ac8ef975f= 1773a142db009105891f06b37cf > 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 =E2=80=9CSpe= cification > Required=E2=80=9D with an indication that the specification MUST be an RF= C (but > see the > discussion of 6.4.1 below), or as =E2=80=9CRFC Required AND Expert Review= =E2=80=9D. 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. > I think that the "Specification required" is the one that we want as per BCP 26: For the Specification Required policy, review and approval by a designated expert (see Section 5 ) is required, and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. Added it here: https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/9ebd4ec6e1d02= 086ecc49bd688e0ac0165c1fe83 > > > * Registry name: WHIP > > Well, but above you say that the name is "WebRTC-HTTP ingestion protocol > (WHIP) > URIs=E2=80=9D. This needs to be consistent, so IANA (as well as other re= aders) > doesn=E2=80=99t > think you=E2=80=99re talking about two different registries here (and the= re's more > of > this below). > > Done: https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/b6418c5366542= 2855ee686bf0f3f6e3aa9f375a1 > =E2=80=94 Section 6.3 =E2=80=94 > > > This section creates and registers an IETF URN Sub-namespace for > > use in the WHIP specifications and future extensions. > > I don=E2=80=99t understand: the first paragraph of 6.2 did that. It seem= s to me > that > this defines the *management* of that sub-namespace, no? > I copied the text from the SCIM RFC: https://www.rfc-editor.org/rfc/rfc7643.html#section-10.1 If I understood the IANA process, the section 6.1 just notes that IANA is asked to create and register a subspace, and provides the template required in rfc3553 for doing so, pointing to section 6.2 as the Repository for the subspace. The section 6.2 is the actual section that creates the subspace. > > =E2=80=94 Section 6.4.1 =E2=80=94 Will send a different email for discussing 6.4.1 =E2=80=94 Section 6.4.2 =E2=80=94 > > > Description: A short phrase describing the function of the extension > > I suspect =E2=80=9Cshort phrase=E2=80=9D is not adequate, and we=E2=80=99= ll just wind up with a > repetition of the =E2=80=9CName=E2=80=9D, as perhaps, =E2=80=9CName: Farb= le bender; Description: > Bends > the farble=E2=80=9D. I would say, =E2=80=9CA brief description of the fu= nction of the > extension, in a short paragraph or two.=E2=80=9D Done: https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/efb80c23d4231= f2aeb3762aa4b057b7210a51e02 I think the changes above address your initial review, but please let me know if you feel there should be any further changes required. Best regards Sergio --000000000000d1e27d05ff413329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thank you very muc= h for your review, I have fixed some of the issues you raised in your revie= w, but I would need some feedback=C2=A0for the main ones regarding IANA reg= istration.
I will address that in a different email so we can dis= cuss it easily by email

On Sun, Jun 11, 2023 at 8:18=E2=80=AFPM Barry Leiba = via Datatracker <noreply@ietf.org> wrote:
Mur= ray has specifically asked for a review of the IANA Considerations section,=
and I have a bunch of comments there.=C2=A0 One general comment first, thou= gh:

Throughout the document you refer to both =E2=80=9CURI=E2=80=9D and =E2=80= =9CURL=E2=80=9D, seemingly
interchangably.=C2=A0 I would feel much better if you stuck with =E2=80=9CU= RI=E2=80=9D consistently
throughout.=C2=A0 For example, in Section 4.4:

> Each STUN/TURN server will be returned using the "Link" head= er
> field [RFC8288] with a "rel" attribute value of "ice-se= rver".
> 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 =E2=80=9CUR= L=E2=80=9D in
either; the both say =E2=80=9CURI=E2=80=9D, and anyone looking in them for = =E2=80=9Cthe server URL=E2=80=9D
will not find it.

=C2=A0

Now for the registration stuff...

=E2=80=94 Section 6.2 =E2=80=94

> 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.=C2=A0 It should say =E2=80=9CIANA is asked to a= dd an entry=E2=80=A6 and
create=E2=80=A6 .=E2=80=9D=C2=A0 The RFC Editor will change the text once t= hat=E2=80=99s 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.<= br>
Similarly here, =E2=80=9CIANA is asked to create=E2=80=A6 which will be use= d=E2=80=A6 .=E2=80=9D

Done:
=C2=A0
=C2=A0 Also= , IANA
will ask you about the BCP 26 policy for registrations here.=C2=A0 The late= r text
seems to indicate that the policy should either be listed as =E2=80=9CSpeci= fication
Required=E2=80=9D with an indication that the specification MUST be an RFC = (but see the
discussion of 6.4.1 below), or as =E2=80=9CRFC Required AND Expert Review= =E2=80=9D.=C2=A0 The latter
is probably better, I think.=C2=A0 Or maybe it's *just* "Specifica= tion Required",
and the type of specification is at the judgment of the designated expert b= ased
on information given here.=C2=A0 In any case, that should be clearly specif= ied in
6.2.

I think that the "Specificati= on required" is the one that we want as per BCP 26:

   For the Speci=
fication Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.
<= /div>

Added it here:
=C2=A0

> * Registry name: WHIP

Well, but above you say that the name is "WebRTC-HTTP ingestion protoc= ol (WHIP)
URIs=E2=80=9D.=C2=A0 This needs to be consistent, so IANA (as well as other= readers) doesn=E2=80=99t
think you=E2=80=99re talking about two different registries here (and there= 's more of
this below).

Done:
=C2=A0
=E2=80=94 Section 6.3 =E2=80=94

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

I don=E2=80=99t understand: the first paragraph of 6.2 did that.=C2=A0 It s= eems to me that
this defines the *management* of that sub-namespace, no?

I copied the text from the SCIM RFC:=C2=A0https://www.rfc-edito= r.org/rfc/rfc7643.html#section-10.1

If I under= stood the IANA process, the section 6.1 just notes that IANA is asked to=C2= =A0 create and register a subspace, and provides the template required in= =C2=A0rfc3553 for doing so, pointing to section 6.2 as the Repository for t= he subspace.
The section 6.2 is the actual section that creates t= he subspace.
=C2=A0

=E2=80=94 Section 6.4.1 =E2=80=94

=C2=A0Wil= l send a different email for discussing 6.4.1

=E2=80=94 Section 6.4.2 =E2=80=94<= br>
> Description: A short phrase describing the function of the extension
I suspect =E2=80=9Cshort phrase=E2=80=9D is not adequate, and we=E2=80=99ll= just wind up with a
repetition of the =E2=80=9CName=E2=80=9D, as perhaps, =E2=80=9CName: Farble= bender; Description: Bends
the farble=E2=80=9D.=C2=A0 I would say, =E2=80=9CA brief description of the= function of the
extension, in a short paragraph or two.=E2=80=9D
Done:=C2= =A0

I think the changes above address y= our initial review, but please let me know if you feel there should be any = further changes required.

Best regards
S= ergio
=C2=A0
--000000000000d1e27d05ff413329--