Re: [Ppm] Versioning for DAP drafts

Tim Geoghegan <timg@letsencrypt.org> Wed, 03 August 2022 23:44 UTC

Return-Path: <timg@letsencrypt.org>
X-Original-To: ppm@ietfa.amsl.com
Delivered-To: ppm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133EAC14CF10 for <ppm@ietfa.amsl.com>; Wed, 3 Aug 2022 16:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 BBEp0bYNi3JZ for <ppm@ietfa.amsl.com>; Wed, 3 Aug 2022 16:44:44 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 462B3C14F74B for <ppm@ietf.org>; Wed, 3 Aug 2022 16:44:44 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id a13so20435975ljr.11 for <ppm@ietf.org>; Wed, 03 Aug 2022 16:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=267mHPbtECmKy731Spvo8Z0RKBkDRbV19YI9K53Qqik=; b=JMs69VC/I65o02/HwZQEuQiT4bu3MW1Wd+ptmyz2PI2y1FPlacfxubST0oNJzOXdAM uiFQOu0D2TBqM6fv0TfrHbveylTXm17/zbEIZRAIe32P27DAwaBU/qzmS1ZN3ZC1wAwp zL2yAxQ24gBo188RQO0y6dPyXMjGs2/RnRP28=
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=267mHPbtECmKy731Spvo8Z0RKBkDRbV19YI9K53Qqik=; b=jnrUkVdUrAGZOTqfd1p1ZBHh5e9mLeG4ntsvSJ2YJ4/K/e9gLOi+SmmkDuHr4kPYet YJyX9aGf1lN5FleZv7uwutyco2xSVRWCeK5eqruZprVcIA9E6EXgFM8nIPp2sLQx3QrC 9BpUwaBZwVMwZcLRV/ZZoZsxS7R13QjafWdpAPSSUvDmEP54CWXlGqOm4lmgGyeImeOd l+o1jnJ2Egu+4JYEBq6WaTMkXoeP9OVKOEhPRyKIFf7heSHR2OWC3rZhLIREUVs9oi97 nVLru/fbWu1UCrZ9BNzCxjD+5rGSNFKXs3iY/1/mYA9IKzRraRr+go8KBVmSOPNAehI9 L7yw==
X-Gm-Message-State: AJIora+f8ENGPMmcckFE6SHmHDi0/fVHk9eLvuaqaGjl+q9lMeMII7jY v+SH1Wy2KnPNNIiClxHqSgCZgwFCSfxSB+FvE9rpcw==
X-Google-Smtp-Source: AGRyM1skorAuzuRmmsxVBdA04ZOJYrArmaFSasmBgQ6Uo1V2dWmrLD4+AnOJ8x5CSYojlOdJKQFd5dccpu55W+xG0oU=
X-Received: by 2002:a2e:b88b:0:b0:25d:a15a:bba9 with SMTP id r11-20020a2eb88b000000b0025da15abba9mr9247883ljp.357.1659570281957; Wed, 03 Aug 2022 16:44:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAG2Zi233rdc9XVS7euSDjw4UtgEYUzR_7hozZFk1iHOCtnrE+w@mail.gmail.com> <CABN231pSMmxRXbiKHpQv8PDQEKyD=5icx-rnWJYdo=Nje73v4Q@mail.gmail.com> <CAG2Zi20oWT3MHh70-LpOfT26dtCmojR-CENe0Ykq+uo0+Qxkhg@mail.gmail.com> <CAG2Zi21Yjiu=syjo=RZaRc9w3u6POySXDUUQ3AoejHrBNztnfw@mail.gmail.com>
In-Reply-To: <CAG2Zi21Yjiu=syjo=RZaRc9w3u6POySXDUUQ3AoejHrBNztnfw@mail.gmail.com>
From: Tim Geoghegan <timg@letsencrypt.org>
Date: Wed, 03 Aug 2022 16:44:30 -0700
Message-ID: <CABN231qYCpEKD7bU6uKu24UfKwD-=1p1fvRHrN7qXBGnKBrAgw@mail.gmail.com>
To: Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>
Cc: Christopher Patton <cpatton@cloudflare.com>, ppm <ppm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000022ee3f05e55ed1ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppm/2YuzUnTJi6R7biUfKKXJTDtABO8>
Subject: Re: [Ppm] Versioning for DAP drafts
X-BeenThere: ppm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Preserving Measurement technologies <ppm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppm>, <mailto:ppm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ppm/>
List-Post: <mailto:ppm@ietf.org>
List-Help: <mailto:ppm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppm>, <mailto:ppm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 23:44:49 -0000

I understand your desire to maintain a single branch and a single
deployment. Having read your initial post again, more carefully, I think I
am arguing for your option #3: 'instead of POSTing reports to "/upload",
clients would POST to "/02/upload"'.

The document currently says you have to support an HTTP endpoint
`[leader]/upload`. So you could have both `dap.cjpatton.com/01/upload` and `
dap.cjpatton.com/02/upload`, and both paths are handled by the same backend
server. But I don't think we need to spell out anything about this in the
protocol text, since it's up to an individual deployment to decide what
`[leader]` or `[helper]` expands to.

Tim

On Wed, Aug 3, 2022 at 3:02 PM Christopher Patton <cpatton=
40cloudflare.com@dmarc.ietf.org> wrote:

> Let me be a bit more concrete about the problem this would solve for me: I
> am planning to have to maintain multiple implementations of DAP
> simultaneously. There's two ways you can imagine doing this:
> 1. Create a branch for each DAP draft
> 2. Implement all drafts on the same branch
>
> Now consider the cost of applying a bug fix that impacts all drafts. If I
> do (1.) then I have to merge that bug fix into each of the drafts. If I do
> (2.) I just have to merge the fix into one branch. The cost of (2.) is that
> we need some way of signaling in-band which draft the peer speaks. The
> upside is a much lower maintenance burden, at least as far as I can see.\
>
> Chris P.
>
>
>> This is perfectly fine for many deployments, but what if you want the
>> same API to support multiple drafts? If our goal is to prevent this from
>> ever happening, then we should at least be explicit about this in the text.
>> (Maybe we are already?)In my opinion, this should not be a goal of the
>> draft. On the road to RFC, some amount of versioning is often inevitable.
>>
>> Another thing worth noting is that whatever we do for in-band versioning
>> can be easily written in a way that makes it opt-in. We certainly don't
>> want to require every implementation to support every draft, or even more
>> than one draft. For example, if we just stick the version in an HTTP header
>> (option #2), then an implementation can simply ignore this if they expect
>> the peer to be using the same draft version. No changes for backwards
>> compatibility would be needed.
>>
>> Finally, I'll just note that this is a temporary situation. Eventually
>> we'll have an RFC and won't need to muck around with drafts. It's worth
>> noting TLS 1.3 went through a couple periods where multiple drafts were
>> deployed on the Internet simultaneously. We managed then and we can manage
>> now. (I realize the situation is inherently different, since TLS happens
>> before HTTP.)
>>
>