From nobody Tue Apr 12 13:05:40 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9133A05F0 for ; Tue, 12 Apr 2022 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.609 X-Spam-Level: X-Spam-Status: No, score=-22.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOI2QHUx93PQ for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC70A3A0597 for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2db2add4516so342947b3.1 for ; Tue, 12 Apr 2022 13:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8I8fos9i12C8L1D2f62pzxQ/0tUdUYLWqN0EiXoMKP0=; b=YglbIPmwS3HTJsLOk/MyLWU4uwQl84S8bBdwzptm33am0AVtauPe0w5u9H8+cFCZWQ RUb5Mq2DtOz+/DaVe7un1Do/Gx2pl45dLv6vDtpCvChb8lJDLhR9UAsUOGucZM0NGxkv KhgsO86u+iLNPFUGQhZ6iQYlVz2SuxpoFeiolsRDyooir3dg7SgPhMLkf3q1bK6yfiMH dhVDk3JeRJ51UZEYb8+Hz3aV8lhq4Yu7JuGXkul2IqtpFPxntwgtmQVk1RALgSOX0Yui 9WUZziVhdG6/gwFCEfPlFprsiWLOD/nYZpqiaMx+9ooxK3zZ0HpAgFPUPDj4/IxxbA+Q NhMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8I8fos9i12C8L1D2f62pzxQ/0tUdUYLWqN0EiXoMKP0=; b=v2LfcD/h5A8iedgMXVGAk1rhZF7frTzY7WEtiyP8OGwRduh4q6FPLOQvoO8eu/uDHA WU7U0wg3fpdqhxsROnTPa1wp2Q6uTz44I6dnSX7BZ5eD/bHhFC43jZ4BZpAj5QjgsvAI d3sgxnC+I8T0+WVy1uYpkgbwauMhTS6xwIanCE2WM/aevVPzpFMwcDF9w/Mu2Ro/C6Xq yZQp4NGY5pmnbWERp6/6rvet0sjzzgeaxgFnrTXu3Kmig0MQNLkmatv6GkT0MGd/hswu RqKSXWv3ZOkjD2GVDeW4dvmI2mJR6z5F2NyTO9k3SoRG1fyK804AO32kwDvzGpq4LZqm vSLg== X-Gm-Message-State: AOAM530jN7Akn3CKJKznqVOwlfpNXwJJF/QZyZBRYEZanbXjiP7ioibN I7/gOqhnJSpBkK+HdLbAv5sEZrCHN/uz+7lDIo6BqW9WDqU= X-Google-Smtp-Source: ABdhPJwrzEsdPN1/pDmj7tNJBog/18uUONK8kASpzzhQRvWswT5LoxhU+gx2vwZBkX+1bA1C/oRNADH26akz2bN+3+E= X-Received: by 2002:a0d:e5c3:0:b0:2ec:49e1:67d7 with SMTP id o186-20020a0de5c3000000b002ec49e167d7mr7183693ywe.166.1649793931189; Tue, 12 Apr 2022 13:05:31 -0700 (PDT) MIME-Version: 1.0 References: <66256ce9-bb9f-4534-87ff-c589566db395@www.fastmail.com> <79e252e5-6aae-5dca-2d49-3ee6aa85f558@bellis.me.uk> <31074d1e-7ec3-4851-90c6-b55f0cdc802a@beta.fastmail.com> In-Reply-To: From: Eric Orth Date: Tue, 12 Apr 2022 16:05:20 -0400 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="00000000000038ede805dc7a953a" Archived-At: Subject: Re: [DNSOP] IANA Policy for SVCB X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:05:39 -0000 --00000000000038ede805dc7a953a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm happy as long as things are still fast and easy enough to support new/experimental/prototype usage. I think Expert Review with the proposed stuff for that expert to review is all reasonable for that goal. If we start getting into stricter bars than Expert Review, that's where we'd have to start discussing the complexity of breaking off separate private-use and experimental blocks with a lower bar. On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren wrote: > I think Expert Review makes sense (with the expert reviewing the SHOULD > around the specification). > > On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: > >> I agree with Tommy. >> >> Selecting an expert who is able to recognize when wider review might hel= p >> is a far lower bar than the one Ray suggests might be necessary. >> >> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: >> > If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed >> > the mark. The space is designed to be large (65K) to allow new work to >> > easily use this extensibility. We don=E2=80=99t need to be too conserv= ative >> > with this space. >> > >> > I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the >> > document who have seen it through, and we have more people using this >> > RR and gaining expertise. >> > >> > Expert review is the right balance here. >> > >> > Tommy >> > >> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy >> wrote: >> >> >> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: >> >>> I am concerned that the set of Expert Reviewers necessary to handle >> SVCB >> >>> needs to have both expert DNS experience *and* detailed knowledge of >> the >> >>> SVCB model for this to work. >> >>> >> >>> I am not sure there's anybody who fits that criteria. >> >> >> >> Specification Required also assumes a community that can produce them= , >> which presumably contains the right experts. >> >> >> >> Are we actually moving toward IETF Review here? >> >> >> >> -MSK >> >> _______________________________________________ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000038ede805dc7a953a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy as long as things are still fast and easy en= ough to support new/experimental/prototype usage.=C2=A0 I think Expert Revi= ew with the proposed stuff for that expert to review is all reasonable for = that goal.=C2=A0 If we start getting into stricter bars than Expert Review,= that's where we'd have to start discussing the complexity of break= ing off separate private-use and experimental blocks with a lower bar.
On Tu= e, Apr 12, 2022 at 3:10 PM Erik Nygren <erik+ietf@nygren.org> wrote:
I think Expert Review makes sense = (with the expert reviewing the SHOULD around the specification).
<= /div>
O= n Tue, Mar 22, 2022 at 8:34 PM Martin Thomson <mt@lowentropy.net> wrote:
I agree with Tommy.

Selecting an expert who is able to recognize when wider review might help i= s a far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we=E2=80=99ll have= missed
> the mark. The space is designed to be large (65K) to allow new work to=
> easily use this extensibility. We don=E2=80=99t need to be too conserv= ative
> with this space.
>
> I disagree that there wouldn=E2=80=99t be good experts =E2=80=94 we ha= ve authors of the
> document who have seen it through, and we have more people using this =
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
>>
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis <ray@bellis.me.uk> wrote:
>>> I am concerned that the set of Expert Reviewers necessary to h= andle SVCB
>>> needs to have both expert DNS experience *and* detailed knowle= dge of the
>>> SVCB model for this to work.
>>>
>>> I am not sure there's anybody who fits that criteria.
>>
>> Specification Required also assumes a community that can produce t= hem, which presumably contains the right experts.
>>
>> Are we actually moving toward IETF Review here?
>>
>> -MSK
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000038ede805dc7a953a--