Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Ben Schwartz <bemasc@google.com> Wed, 07 September 2022 21:21 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 C0C4EC14CE2D for <dnsop@ietfa.amsl.com>; Wed, 7 Sep 2022 14:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.606
X-Spam-Level:
X-Spam-Status: No, score=-22.606 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, 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, 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 bWWar3dvAWVF for <dnsop@ietfa.amsl.com>; Wed, 7 Sep 2022 14:21:23 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 BCE13C14CF12 for <dnsop@ietf.org>; Wed, 7 Sep 2022 14:21:23 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id t14so15276048wrx.8 for <dnsop@ietf.org>; Wed, 07 Sep 2022 14:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=mM+zEuHSdjb4YQwjh4tFxZV3v7B2xT1ifJAwWn123xI=; b=odIbIGmxcdwR+i82ZmmTxg932TrNVzbEP2JxPKnm2ktpPnDxHSVqQZgmRlijiURKtk wSx0Iz58o2A+WoW5jMo/0m4RlbX2QNjARXlIjrU3q7ml1qgnRM/VUErUepYRY68+dUvO YeMNf/pGr/E9fO7BfeXBjfmuuU9R3RBSsoPdGv2BiiHauX0j4DUPM1Jm+Ke7+FDIdbcE dnf8qtRXvc7BEpLXrw7kMkuw4RbkTkiYjwnGEi3yZEpGPYSH+hh/jtM8V7QGoMLRNrPn 5NrzqY21+afkbWaDqZUHVok3Knf7S/6+iWoRqr9+AX9GanKSfScJ1za44A/ol8deEkoK CUZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=mM+zEuHSdjb4YQwjh4tFxZV3v7B2xT1ifJAwWn123xI=; b=6J6rc9qLUeJIXrTV7oQ1sYGKLK+CdpdZUcPPt4fKs9z3C0DUHrpZFBXLPQEsKdKTNt V4KR70/eDhxm59riADNxQjfp/Bokq1G+9rukwC64iH5yW0QNWqlYAGop+oxm6TYFKDpv /LeuVvZMTIj4wjyeoCK/Zbia+KCQFnp/D3vgGm04jTurX5xX881GKs1vjO2EZYX7YEZA cZWsePEvraFbggoXCHLGBJoV368eSQ2S9hu1DJnzl73tP2utUw5dwMFcQCsqwe+bk2Iv 7KXgOkfFCHv/T6PpP/EmBHw8LT/YQ7TiEIdX55bAhmkHpLuJCn3qFZrImvWydWxoCyWq gIAA==
X-Gm-Message-State: ACgBeo0YznZJ2ZKUZw0fKM7AkVqohenMYvoHbtAPB7jyOzZJEUOGjprv PUapbnUclNm7A6+XyqONWnInPpa6dooGmO48KrBD7A==
X-Google-Smtp-Source: AA6agR7FdzSePhvjyx/sbfEhf0cSijdUiL35ZwcNxoOBzMzoCkICv9MwV6SbOm73WdUCCunrDgPN+xO/Pb7KLmYrOQ4=
X-Received: by 2002:adf:ee89:0:b0:228:7bdf:47d with SMTP id b9-20020adfee89000000b002287bdf047dmr3145565wro.641.1662585681589; Wed, 07 Sep 2022 14:21:21 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKZJndu1100LBU3TiuhF9ACb0As2deA1oZWD2eA46tBbA@mail.gmail.com> <CAH1iCiqryY=u6MN2mkf7krHLmc7TQkoDaXe0k=ZZ+0e9uiMb-Q@mail.gmail.com> <YwaQrnoA3hifxCQW@straasha.imrryr.org> <CAMOjQcEcKQSWvb_LqmfkGwZ2dt_561jLZxHTMuMO0pMy2s9mbw@mail.gmail.com> <CAH1iCirnWdDY0p2-grQKN3PQWOM=JLevxbNskFFEzGwHvisGZA@mail.gmail.com> <B024358C-77FD-4E63-8E18-1CBCEA6C6B14@icann.org> <CAH1iCiry3VDS+dM+wEkPH5a_TSt5pEddxPjKOhL9_M20e_dR0A@mail.gmail.com> <8B970775-22CF-403B-9B8A-84DCC0932D76@icann.org> <CAHbrMsC_RO1J6qp_yOWOc3P4zpZ-cOCB6adXRwjoSQP7_yrWug@mail.gmail.com> <CAH1iCiqzeZORDmbE+XMs1wt6YZKYFZWnsnrvN8fbLHpFXEfDfw@mail.gmail.com> <CAHbrMsDSbDapPFFfhU1iyi5BpEjb8NA7WXz+1pu78dGnuVkNzg@mail.gmail.com> <CAH1iCiojyT47nvNqeCkz8X4ueY0y_fp11BNEoV6WMuWx639_Dg@mail.gmail.com> <CAH1iCipRjnvs71iiK1aaMKj98P65-NqKSL4+XfmMA_MsU9_JNg@mail.gmail.com> <CAHw9_iJg7yTECPbPvSNxac21My4SqPjMjhYS4tFRWBzFmjkLjg@mail.gmail.com> <CAH1iCipoo2u2h8XtJp8iwrg-bonMC785RehC3bVzbMKaLv+Kpg@mail.gmail.com> <0203FD85-487D-4B64-88BF-818B5BE0BC70@apple.com>
In-Reply-To: <0203FD85-487D-4B64-88BF-818B5BE0BC70@apple.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 07 Sep 2022 17:20:34 -0400
Message-ID: <CAHbrMsCZSkakKvnxTsqQ0JmywNAHwVC1DyN0aVJ72sH7fgy6pA@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Warren Kumari <warren@kumari.net>, draft-ietf-dnsop-svcb-https.all@ietf.org, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000fd3e0f05e81ce4ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2Id94OZ__ryeP_T8waqIieS85Zs>
Subject: Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 07 Sep 2022 21:21:25 -0000
As I noted earlier, changing the non-SVCB fallback recommendation to "MAY" would nominally make HTTPS-record deployment riskier. I'm inclined to take the current approach (encouraging fallback when it is safe) for now, and perhaps revisit this question in a few years if operational experience shows it to be unnecessary. On Wed, Aug 31, 2022 at 11:00 PM Tommy Pauly <tpauly@apple.com> wrote: > I don’t personally find this proposal to be an improvement for clarity. > > The fact that a client is SVCB-optional means, somewhat by definition, > that they allow not using the SVCB results. Saying that the client “MAY” > doesn’t really help; it’s the very definition of what SVCB-optional is. If > the client doesn’t use non-SVCB connection modes at that point, then it is > SVCB-reliant. > > Listing out the details of what a non-SVCB connection does (not using the > information from the SVCB record) also seems redundant. It is more accurate > to just say “don’t use anything from SVCB if SVCB didn’t work” rather than > trying to list out what all of those details might be. > > Tommy > > On Aug 31, 2022, at 4:13 PM, Brian Dickson <brian.peter.dickson@GMAIL.COM> > wrote: > > So, here is my suggestion, for "a sentence (or possibly two) which only > clarify what is already written?": > > In section 3: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > > becomes: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client MAY attempt to use non-SVCB > connection modes, using the origin name (without prefixes), > > the authority endpoint's port number, and no SvcParams. > > (The original didn't use RFC 2119 language, but the list of failure modes > in 3.1 leads to "MAY" being the most appropriate choice.) > > Let me know if that is good enough. > (The rest can go into a -bis... how soon are we allowed to start a -bis > document? The day of RFC publication? I'd like to start that as soon as > possible, while everything is still fresh.) > > Brian > > On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari <warren@kumari.net> wrote: > >> >> >> >> >> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson < >> brian.peter.dickson@gmail.com> wrote: >> >>> Here are some proposed text changes, per Warren's invitation to send >>> text: >>> >> >> >> Um, no. Warren said: "can we craft a sentence (or possibly two) which >> only clarify what is already written?". This is a significantly larger set >> of changes than that. The Section 3 changes in particular are (IMO) much >> more than a clarification. >> >> These may or may not be good changes, but anything approaching that level >> of change would have to be in a -bis document… >> >> W >> >> >> >>> In section 1.2, change: >>> >>> 2. TargetName: The domain name of either the alias target (for >>> AliasMode) or the alternative endpoint (for ServiceMode). >>> >>> to: >>> >>> 2. TargetName: Either the domain name of the alias target (for >>> AliasMode) or the host name of the alternative endpoint (for >>> ServiceMode). >>> >>> In section 2.4.2, change: >>> >>> As legacy clients will not know to use this record, service operators >>> will likely need to retain fallback AAAA and A records alongside this >>> SVCB record, although in a common case the target of the SVCB record >>> might offer better performance, and therefore would be preferable for >>> clients implementing this specification to use. >>> >>> to: >>> >>> As legacy clients will not know to use this record, service operators >>> will likely need to retain fallback AAAA and A records at the service >>> name, >>> although in a common case the target of the SVCB record >>> might offer better performance, and therefore would be preferable for >>> clients implementing this specification to use. >>> >>> >>> In section 2.4.3, change: >>> >>> In ServiceMode, the TargetName and SvcParams within each resource >>> record associate an alternative endpoint for the service with its >>> connection parameters. >>> >>> to: >>> >>> In ServiceMode, the TargetName and SvcParams within each resource >>> record associate an alternative endpoint for the service with its >>> connection parameters. The TargetName MUST be a host name >>> (as defined in [DNSTerm].) >>> >>> In section 3, the following changes are proposed; they introduce a new >>> term LASTNAME to be used to disambiguate the $QNAME reference so as to >>> remove ATTRLEAF prefixes from the appended target: >>> >>> >>> 1. Let $QNAME be the service name plus appropriate prefixes for the >>> scheme (see Section 2.3). >>> >>> becomes: >>> >>> 1. Let $QNAME be the service name plus appropriate prefixes for the >>> scheme (see Section 2.3). Let $LASTNAME be the service name >>> without any prefixes. >>> >>> >>> >>> 3. If an AliasMode SVCB record is returned for $QNAME (after >>> following CNAMEs as normal), set $QNAME to its TargetName >>> (without additional prefixes) and loop back to step 2, subject to >>> chain length limits and loop detection heuristics (see >>> Section 3.1). >>> >>> becomes: >>> >>> 3. If an AliasMode SVCB record is returned for $QNAME (after >>> following CNAMEs as normal), set $QNAME to its TargetName >>> (without additional prefixes), set $LASTNAME to this new $QNAME >>> and loop back to step 2, subject to >>> chain length limits and loop detection heuristics (see >>> Section 3.1). >>> >>> >>> Once SVCB resolution has concluded, whether successful or not, SVCB- >>> optional clients SHALL append to the priority list an endpoint >>> consisting of the final value of $QNAME, the authority endpoint's >>> port number, and no SvcParams. (This endpoint will be attempted >>> before falling back to non-SVCB connection modes. This ensures that >>> SVCB-optional clients will make use of an AliasMode record whose >>> TargetName has A and/or AAAA records but no SVCB records.) >>> >>> becomes: >>> >>> Once SVCB resolution has concluded, whether successful or not, SVCB- >>> optional clients SHALL append to the priority list an endpoint >>> consisting of the final value of $LASTNAME, the authority endpoint's >>> port number, and no SvcParams. (This endpoint will be attempted >>> before falling back to non-SVCB connection modes. This ensures that >>> SVCB-optional clients will make use of an AliasMode record whose >>> TargetName has A and/or AAAA records but no SVCB records.) >>> >>> If the client is SVCB-optional, and connecting using this list of >>> endpoints has failed, the client now attempts to use non-SVCB >>> connection modes. >>> >>> becomes: >>> >>> If the client is SVCB-optional, and connecting using this list of >>> endpoints has failed, the client MAY attempt to use non-SVCB >>> connection modes, using the origin name (without prefixes), >>> >>> the authority endpoint's port number, and no SvcParams. >>> >>> >>> One additional suggested addition to the end of section 3.1 is: >>> >>> If DNS responses are cryptographically protected, and at least >>> one HTTPS AliasMode record has been received successfully, >>> clients MAY apply Section 9.5 (HSTS equivalent) restrictions >>> even when reverting to non-SVCB connection modes. Clients >>> >>> also MAY treat resolution or connection failures subsequent >>> >>> to the initial cryptographically protected AliasMode record >>> >>> as fatal. >>> >>> [Brian's note: this last would provide some guidance to implementers of >>> clients: a signed HTTPS AliasMode record is a strong signal that the DNS >>> operator is discouraging fallback, albeit at a "MAY" level.] >>> >>> NB: The 2.4.3 change could be removed as it is mostly independent, as >>> could the last addition to 3.1. >>> The 1.2 change is very minor, is not too important but presents a >>> succinct clarification on the hostname vs domain name thing. >>> The 2.4.2 change and section 3 changes together are fixes for the >>> prefix/no-prefix issue (which was basically a scrivener's error, and does >>> not change the semantics at all.) They should stay or go as one unit. >>> >>> Brian >>> >>> On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson < >>> brian.peter.dickson@gmail.com> wrote: >>> >>>> >>>> >>>> On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz <bemasc@google.com> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson < >>>>> brian.peter.dickson@gmail.com> wrote: >>>>> >>>>>> >>>>>> Fail fast may not be appealing, but in some (probably the majority >>>>>> of) cases, it may be the most correct option. >>>>>> >>>>>> It may also be the case that the zone owner knows whether this is the >>>>>> case. >>>>>> I think it is much more likely that explicitly declaring the >>>>>> situation (if known) is more useful than having several billion clients >>>>>> independently attempting to infer whether the first option will even work, >>>>>> let alone provide a useful alternative to the second or third. >>>>>> >>>>> >>>>> In fact, there is one way for the zone owner to disable fallback: >>>>> enable ECH. Fallback is not compatible with ECH, so ECH-aware clients will >>>>> disable fallback when the ServiceMode records contain ECH. >>>>> >>>>> >>>> Wait, what? >>>> >>>> This whole discussion was raised from the perspective of zone owners >>>> publishing AliasMode apex records. >>>> Those owners would not be operating the CDN, which is the whole point >>>> of using a CNAME or AliasMode. >>>> I.e., the zone owner would be the one wanting to disable fallback, but >>>> would not be in a position to do what you suggest. >>>> >>>> The domain's contents are served via a CDN, where the CDN requires >>>> delegation of control, most often with CNAME (or AliasMode at the apex). >>>> The ServiceMode records are placed on the CDN operated zone (in order >>>> to avoid the first connection to establish the AltSvc stuff). >>>> >>>> The AliasMode record cannot be combined with ECH, since no SvcParams >>>> are allowed. The zone owner is not using ServiceMode, that is the declared >>>> assumption. >>>> >>>> If that (ECH) is the only way to disable fallback, that's what the >>>> focused discussion needed to elicit, and I think some slight adjustments >>>> are needed to at least facilitate zone owners preventing fallback. The >>>> mechanism doesn't need to be added to the draft, but likely would get put >>>> into a separate draft or a -bis document. However, there needs to be some >>>> daylight between the fallback method and the mandatory SVCB/HTTPS >>>> components, in order to allow for that development. >>>> >>>> BTW, the concern is less about singleton zone owners than it is about >>>> large scale integrated DNS management of zones in order to accommodate CDN >>>> usage. >>>> >>>> Note also, this issue is not strictly limited to vertical integration >>>> among products/services of the DNS operator; there are large scale >>>> inter-provider (DNS and other services) open partnerships (controlled by >>>> their mutual customers) that have need for the programmatic ability to >>>> assign CDNs and enable/disable fallback (if fallback is part of the >>>> specification). >>>> (For those interested, the not-yet-an-IETF standard for >>>> interoperability between DNS and service providers is Domain Connect. The >>>> intent is to revive the draft for that, which previously lived in the >>>> REGEXT WG.) >>>> >>>> I think converting the fallback in the draft into MAY, and having >>>> active discussions, dev, test, and deployment on a voluntary basis outside >>>> of the scope of the current draft, is the fastest path to solving the "no >>>> fallback" signaling issue, and to getting the draft published (with a few >>>> minor tweaks). >>>> >>>> I'll review the other comments, as well as Warren and Viktor's recent >>>> messages, and see if I can come up with some proposed text to make very >>>> limited changes to the draft. >>>> >>>> Brian >>>> >>> >> _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
- [DNSOP] Questions / concerns with draft-ietf-dnso… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] Questions / concerns with draft-ietf-… Brian Dickson
- Re: [DNSOP] Questions / concerns with draft-ietf-… Stephen Farrell
- Re: [DNSOP] Questions / concerns with draft-ietf-… Martin Thomson
- Re: [DNSOP] Questions / concerns with draft-ietf-… Stephen Farrell
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] Questions / concerns with draft-ietf-… Eric Orth
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] Questions / concerns with draft-ietf-… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Eric Orth
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Tommy Pauly
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- [DNSOP] HSTS on receiving a signed HTTPS record (… Martin Thomson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] Questions / concerns with draft-ietf-… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Eric Orth
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Brian Dickson
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Eric Orth
- Re: [DNSOP] [Ext] Questions / concerns with draft… Tommy Pauly
- Re: [DNSOP] HSTS on receiving a signed HTTPS reco… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Ben Schwartz
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Martin Thomson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Brian Dickson
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Viktor Dukhovni
- Re: [DNSOP] [Ext] Questions / concerns with draft… Paul Hoffman
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Warren Kumari
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren
- Re: [DNSOP] [Ext] Questions / concerns with draft… Erik Nygren