Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)

Ben Schwartz <bemasc@google.com> Mon, 23 May 2022 20:53 UTC

Return-Path: <bemasc@google.com>
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 194EBC15AE30 for <dnsop@ietfa.amsl.com>; Mon, 23 May 2022 13:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.599
X-Spam-Level:
X-Spam-Status: No, score=-22.599 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, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kLTzqsPUjHE for <dnsop@ietfa.amsl.com>; Mon, 23 May 2022 13:53:16 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 CB47CC15AE14 for <dnsop@ietf.org>; Mon, 23 May 2022 13:53:16 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id bs5so7658175vkb.4 for <dnsop@ietf.org>; Mon, 23 May 2022 13:53:16 -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 :cc; bh=j1BuNtv1N82V/yE6mRNM+F8PgiP46+/ttLsRuyYYmCo=; b=cZxdR4IrVQeP+l6BSTKJhPMkzv5c9QYTEmyiMsyl5jpPcc4QioziGuEVP5ja+Ymken V3iJr/h1EhvMvXi0G3YHqGktsl6SOtrFCSPCwbp4I7uYth3O4vpFy17Kr3JVQAVI22T5 86IWKg+wfEtC+8WFiHe3C06YnheT4ryZNT9rwYChen2JzARAlSFNfS9xql8ChGUtUAgT fTFmUa3eNLTMxDrj+QXym1JNxMB/u29aCVlEoNkC1whDf4EdA5m+3Zr5ugFq5g1jO1tx hqDhN0JzcgcFL71Jxn08LnOhl+c80DJJMS3Wsg2Ag04TRVG03xSfFYTs0aA67Il5yqaE /Btw==
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:cc; bh=j1BuNtv1N82V/yE6mRNM+F8PgiP46+/ttLsRuyYYmCo=; b=hB3FgglOtdBOOFKBwuKEsVDNZkfgh8UjCZymODkhkDLBPfkeYgn7bzc1s5RrGCG5hi 70oJAhYYM4AcgHsjCuWHMoznzRG6ht5bsmQgLhi3zHjXPqPtkbkjje+BXNkVea/dAyY4 zuEp03CbwZOoO6EpRFlb/1ml+srTzdTxAVoWjDTcEqWG0t2CDZgDRZnBk9AGOKDWLy2j hC9UOvbxgSLhQd2jrwdbphmf6Xx06HYsLj+eaOmoT6ZdSC0xOYCXMaLlHDdvv/DsZTiF NAPko76K9WGNcIxh/TBtDob7qF0CLnG9jLIaHaUd9VhENh+cf+En33Caps+nvoiqzu+R uU+Q==
X-Gm-Message-State: AOAM533TI82e8LbJoc4XOg+CgwIkc0HUaAiuS6riKN/kcxDOHtRmavBq ynWT3ERMGnw5101sJPaVfYdgq3+5Bub9v59BO836tA==
X-Google-Smtp-Source: ABdhPJy2kBUk8T1N4jgdye4SFUpwKhb/akuau4CBBN95pOITaBP9EtmHpKVRjeNgSBf2cx3Ws/h3C9+3PDdrxeOgXlo=
X-Received: by 2002:a05:6122:2228:b0:32d:e4e:a79a with SMTP id bb40-20020a056122222800b0032d0e4ea79amr8281132vkb.27.1653339195332; Mon, 23 May 2022 13:53:15 -0700 (PDT)
MIME-Version: 1.0
References: <165330731633.53326.3094975945466470860@ietfa.amsl.com>
In-Reply-To: <165330731633.53326.3094975945466470860@ietfa.amsl.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 23 May 2022 16:53:04 -0400
Message-ID: <CAHbrMsBM9kfYJg1BGSqkoN4_N6Zo9mqtROtzDBWPNga2TtW4tg@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-svcb-https@ietf.org, dnsop-chairs <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000751b5d05dfb4075d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3lpsbdRxI924pxRwCxMYTGhgCE4>
Subject: Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2022 20:53:21 -0000

On Mon, May 23, 2022 at 8:01 AM Francesca Palombini via Datatracker <
noreply@ietf.org> wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document.
>
> Many thanks to Cullen Jennings for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.
>
> Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed
> v-09
> and I noticed 4 points were not addressed (or I missed them). Do let me
> know if
> you think no further clarifications were necessary - just making sure these
> were not missed, as I have not seen any answers to them.
>
> Re: the use of SHOULD - thank you for adding context to most of them. I
> did not
> see any added context to these following two SHOULDs:
>

OK, I've proposed adjustments to those two SHOULDs at
https://github.com/MikeBishop/dns-alt-svc/pull/392

...

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 4. -----
>
>  The value is then
>    validated and converted into wire-format in a manner specific to each
>    key.
>
> FP: Section 15.3.1 states
>
>    registration policy ([RFC8126], Section 4.5).  The designated expert
>    MUST ensure that the Format Reference is stable and publicly
>    available, and that it specifies how to convert the SvcParamValue's
>    presentation format to wire format.
>
> This covers the conversion, but does not cover the validation mentioned
> above.
> (This could be really easily addressed by making sure that not only it
> specifies how to convert but also how to validate).
>

I don't think this text change is necessary, because any specification of
the conversion necessarily also covers validation.  A "conversion" in this
context is an algorithm that accepts one input (an octet sequence) and
produces one output, which is either an octet sequence or a failure
indication.  If the conversion fails, we say that the input was invalid.

10. -----
>
> Table 1
>
> FP: The table reports that
>
>    | 65280-65534 | N/A             | Private Use    | (This document) |
>
> But that is not specified in the text above, that only talks about expert
> review registration policy. That should be made consistent.
>

This text was slightly adjusted in -09 based on your comment.   It now
reads "_New_ entries in this registry are subject to an Expert Review
registration policy" (emphasis mine).  This is consistent with the example
given in RFC 8126 Section 2.2.

I believe the source of confusion here is that RFC 8126 defines "Private
Use" twice, with incompatible meanings: Section 4.1 describes it as a
Registration Policy, whereas Section 6 defines it as a Registration
Status.  This registry is using the latter definition.