[dconn] Re: Splitting the async flow from draft-ietf-dconn-domainconnect - split into 2 or 3 documents?
Peter Thomassen <peter@desec.io> Thu, 19 March 2026 13:41 UTC
Return-Path: <peter@desec.io>
X-Original-To: dconn@mail2.ietf.org
Delivered-To: dconn@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5BA8DCDF5A59; Thu, 19 Mar 2026 06:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=desec.io
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE7SjA5Fzn78; Thu, 19 Mar 2026 06:41:43 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EEB1FCDF5A54; Thu, 19 Mar 2026 06:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=desec.io; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C4zXgQmtEoaVRLQW4rnPvwzjaVj0DhxecA55posYtBw=; b=Vazt3As93+5I70KkY5xQYhvT/M Jy19YrGDTj2hwTFHXA71tQCvZTsUPR6+p0spC3rPdUbXGTcDWIIwFGicpZ9x/lRlFz8I7OQuYwaXp o4E+c+ktdXvtm6Ul1wsfBruvxku7eLwrNMkY6gTmqde/y8hHsMn3N5ib7M1o0BuotVoAXe3OMUfux 8lwf5WI2AM3XTCuB2dFgbJuwBXV/YuhJ7tkTsIMBwjY1O4yLbYhbbtBViGN1rZpfyPPtht4TDKGw9 zacyFv8J4wn509g33wW1KsTxeBzr1gfDVgYT9A2SGeiV4+wVkA0YxucpZgXTtOAO1SG45rO8HIlcz 4aC5A8gw==;
Received: from archive.a4a.de ([88.99.107.171] helo=[10.10.0.2]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97) (envelope-from <peter@desec.io>) id 1w3Dd8-00000007qey-1X9b; Thu, 19 Mar 2026 14:41:43 +0100
Message-ID: <40897771-4e06-41fd-91b2-5985c65a7851@desec.io>
Date: Thu, 19 Mar 2026 21:41:37 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Pawel Kowalik <kowalik=40denic.de@dmarc.ietf.org>, "dconn@ietf.org" <dconn@ietf.org>
References: <955d2abe-40c5-4217-9905-74d1b31de4ac@denic.de>
Content-Language: en-US, de-DE
From: Peter Thomassen <peter@desec.io>
Autocrypt: addr=peter@desec.io; keydata= xsFNBFRjVn0BEADXqtra70yxQrT4MQ9DEhN0mxG6XRAOHE6nP18mqxwSlcET7D6w+z3h4ole v0tyvUU02c2wg04X8WVfjoHnAvIa1dfUcNpB1+QmfFsw0xIJlbT1ogHkMiPQqR4ChDvE3ND/ 6YCS5+HT6hY+tfU+hpLsKw4l+u1Pg2NPVLYosET1jU84b7xhFnoicnCV3kUNltLtxLKSBAfk AXtp1AWWKJbfCr3y0qKElMriicoe5DUZfLrZK2iPcWBxh+n7KMO2g7aqx3aQqwW1+S7Sq7Is l6iSurYfIcHb4AfUy4o5nPB8kKACR6BuJmkEQ5WLuTGruWA2fcxaNpICmolMinTzW1CrIjgN PoskMYCNIZ2uWxS6LN8hBiGCRL4h9aL4wuT09SvR13oAPI1HD5ph+mH6wD37/ONBXrdjcFNb 1l/uVkHU/SwwcKDJOsX18T60Ao00fciTbFHgmKtFube0xGK/vjh461TyU+xKD8Orvyeovvxy MzCwM3UVq/dkdG2Ys/7Qy/4bUC1nJEwKlLv7ZTdtSckdoU2M6JpPX6i4KDB2YCMbwtqJ842z 8A/UuE2bL9aDimh/sF8WgPIhlxqF1STNqW1JTIbDPv8HeZnM4nyJOUWStj4uRiETQhBClPLz YWtnR+EUsfbSLy81vfupbMqRasDlt6aASobgn+K7Rb1Xs/mDnwARAQABzSBQZXRlciBUaG9t YXNzZW4gPHBldGVyQGRlc2VjLmlvPsLBeAQTAQIAIgUCVGNWfQIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQ79YUOj7yLS88Dg//SbHnFGrtaImEiM69wyj4GzWnuGk9/upCym/R RzdBALCYHU9FUFFHwusiO9A0pnO8qv/GEtqqTHrcL205a6FTivkdZmOsWuN4oo7r4HBc/taI FLLUDg2wd8q4m4387sYEqrc3olGfyRB6hrMtEWVJLXHJmpcrxAaI1F2QO4Bu7kcdTnyGFz/p ZD8XAof2TWHqJb2ux69DFhiAJeAZlV+h9QrxTedL84l4hq3x1VWsnOEFaCJiThDX920kTnhJ ijrDocgAbmQBCniPACpPHYhBhmCJxfVqgfMuLMNsukOmKxsGcGV6rO1zB5ZUhm3O/Ixk6ow3 6FDKALWihg6Z4P/cJYySMn0iqvHkO8ryT9oJKX//mKaYoF6henXDRLCcRjKwGxFQTEgX+6yc pjgvX3rlypjkPT5ho4yEc5ePkQ2gIIHhvZburm1Zr4nDPx6v8+3XUjpXBRTWQ8/0/h0rtLJe yOPwGJxcfKf/GutTCqiio0mS01mIY9c2i7JWcljlIuSEUit6CHotc5lBOm2GJwguRJG6cXPY SQecwBdcjH3RTzBOv/DN6xWAIV7BmbX/e7DSGAc60mBO1/M0ut+a6CkxRQK8TaE3B3zh1/QO nG0XvtZfIY8ZYdTrdEDSV1Pj5pof/fqhhegHRxN2qi4qIuVcrW0jsUsx10IgAynHR7qQKsvO wU0EVGNWfQEQAPBA8iPCS4ZRX8stW0WuW7579axSq/Luyik4MWDFalt68lzvUbV0f6faN15+ aV7VwMTw3rSa2tP0U8crYAAAZ5NrRHXlYms5BK9vsi1322dAvhyNRawdprP627SO+Ez/84tY xz1X3M9esbN7gpJtHP6mHW76zYpT447v6c2qlbldjobZTDb6kKSGFCIrPJz9M4jVfya+ovxe 2Ab7hn2R0CcyMHATV5g1Ry0XXaj5y3bWypActbG9nflRn3NjhHZynu+WEPDUJCO8kNVNYKOw HObNTeaLvgvU0ONB8pYJv35kDXMhZLwo5MJuJd5i54CXwpo9mECwLJT1RpJi7u98nBrWyyaH s2brG9LPCRKBKOhiHFu57H+cElh+kOvehuS7DFTzjqDwJlkQzP5Hq0G++hZxfdYocKdcdFoh RP3dtDAe+Lfiy9qzJicZ6ACbzoQIN58xj0VWAn1W7SuMErOjv84D/FiXHD2Kxtx09wQl8vH0 Nbh9UgyDBNupToM0ixT+8Ko8eBuYHR53RPxshQhFw4EMIhXiOaxNe1W2Z95QPnYhUGOMoy3I v4fxMQUHa4kZSF2qxsFB1Cxol/aBPGwkwoqUvzp23pLQtJ6youYXtLgvx3pR4L52Q5CUzHMa HvM67XWgW1KqtnvNBXN9PwtDz/a9fQX1YO4CegrXv8C9Ro+LABEBAAHCwV8EGAECAAkFAlRj Vn0CGwwACgkQ79YUOj7yLS8rXA/9EGX2QRfJS94JTdtseu7saTK9a3IKwk6E33GpfXyUVpMt sOqV756XQwULZSWoxInRQtWojA8pQxDUYrbA4MpX0Efr2Dx1xIsJ5F3JajOqViB1SbOD2m0f bxXbcoWKitsKoag2SlvNOd8rD9FcgDvrkacnaQZcZE8DyyGx0JU451tfoD/igu85NZpTDaWG 6fth7QRlxmdGWrGXRdXAP29jq1n0I1wIyF/bXlZ7MXjOSsfyPddzsnHFTvNMZKps0QXNF+hi ESg9chIeo/IFDDVu6pCtm6mftojx84rczTZiNk8r2T3TU4N8uwWtXn/nj9xd61pnxD0xkTPH zxJrCs59WSfYqj3aFNkWO3Lg0/HGnO9wHQKMXcGPsnKITHVzxCNBQtVHomNA7ds6Kt3/WJgS pU2ciICvrpvKgPNWQ0d/SeY3vYIRvDLZ12Svx6M3eXDrsgZOT5be7kGVr3t7dBOYKcRHkZUq kU1kCcgp0vetISVDOc5fkpdUkAtd5/13pIpz4ikVR3OM4Br4XMVShm6RvoP4pyA+ftCi1+bw 0UbRCrnHgnG+wtCf5nMDGVLc04vITnII+ESZqlF02a1IFj0Z2MuQK2Oszl2Nsx/LG60G1e/R pzKEXIIJgHfbwUCWtV1zQu6v9Ng5H8EqVeWcdaPUwSQMGcDg/sPa4s/OxhgrYBg=
In-Reply-To: <955d2abe-40c5-4217-9905-74d1b31de4ac@denic.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: LZC6Z2YQLMXQZ2FO2PYBRS6NAOSTRD7M
X-Message-ID-Hash: LZC6Z2YQLMXQZ2FO2PYBRS6NAOSTRD7M
X-MailFrom: peter@desec.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dconn] Re: Splitting the async flow from draft-ietf-dconn-domainconnect - split into 2 or 3 documents?
List-Id: "Domain Connect is a protocol that makes it easy for a user to configure DNS for a domain running at a DNS provider to work with a Service running at an independent Service Provider." <dconn.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dconn/zqtEikLkxRxBM0c6NWHZnM8KxqQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dconn>
List-Help: <mailto:dconn-request@ietf.org?subject=help>
List-Owner: <mailto:dconn-owner@ietf.org>
List-Post: <mailto:dconn@ietf.org>
List-Subscribe: <mailto:dconn-join@ietf.org>
List-Unsubscribe: <mailto:dconn-leave@ietf.org>
Dear WG, For the record, chairs will await this split-off (whichever way it ends up being) and request a DNS directorate review afterwards. Best, Peter On 3/19/26 20:39, Pawel Kowalik wrote: > Hi, > > today in IETF 125 DCONN session we discussed splitting async flow out of the core spec to a separate document. > > TL; DR; split into 2 or 3 documents? > > Below the rationale from the slides. The consensus in the room was clearly to follow the proposal. > > The editors will follow up on this with the required changes, likely renaming the drafts to draft-ietf-dconn-sync and draft-ietf-dconn-async to be able to easily take them apart. > > There was one voice in the room to split into 3 documents - "core", sync and async. > > Theoretically this could work as well. An implementation of just "core" and "async" would still make up for a working setup, however "core" alone would not have a standalone value, so at least 2 documents would have to be published together. > Any opinion from WG? > > From Slides [1]: > - The draft is still quite long. 82 pages of -01. > - Quite bit of content was removed, but the number of pages grew from 72 in -00. > - Shall WG look at further reductions of the “core” draft? > > - all elements are considered core from the perspective of original domain connect protocol > - Async flow can be considered separately (15 pages), and extendible Settings End Point allows for split away > - Proposal: focus of “core of core” – sync flow and split away async as a second standard track document > > [1] https://datatracker.ietf.org/meeting/125/materials/slides-125-dconn-ietf-125-kowalik-domain-connect-01 > > > Kind Regards, > Pawel > > > _______________________________________________ > dconn mailing list -- dconn@ietf.org > To unsubscribe send an email to dconn-leave@ietf.org -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
- [dconn] Splitting the async flow from draft-ietf-… Pawel Kowalik
- [dconn] Re: Splitting the async flow from draft-i… Peter Thomassen