Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Brian Dickson <brian.peter.dickson@gmail.com> Tue, 11 May 2021 21:31 UTC
Return-Path: <brian.peter.dickson@gmail.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 246F03A2738 for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 14:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8OLwnU1Aa7OX for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 14:30:57 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 2EB8A3A273A for <dnsop@ietf.org>; Tue, 11 May 2021 14:30:56 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id h4so30777664lfv.0 for <dnsop@ietf.org>; Tue, 11 May 2021 14:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2gc8H+SgTwzMgSFFH05xIoYHDl72E8piEbsfHboqpWI=; b=Qv6W3IMd7KfV/f3Q1php2SbKieYSDtBtOhXH0PchjQDgxVu/kvQhGBZEQWW1gtJqLK uCeTCgdC0iwCVBAjd4Yb2zE7Z2I7QH8XMMU8r4xUxLtrKE1VB4tqCT08/cU6MNAD/TV8 8Vo6gg7ABtII6AghLRV6ACEiwAhgcSFxHlGuzp1uBvieYfNbNz19rG8vBkjGY6aRg5Po 04ZZ1E/JjzLT3VTcooyFyWWitz2GuvFdOs4k7LRxiR+wqLLQhEIgcGQU51wQOpFTAQ0s 6LJ2RtUTERkjD0hf7zyiPde7ztF/OjOFG+thSq/V+j7dw4So9/KxfiEbJ5kzclRxzn4Q Niuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2gc8H+SgTwzMgSFFH05xIoYHDl72E8piEbsfHboqpWI=; b=ibRzgyofNbs91LR7y7So5UpA0ugWcBd4zow5IBdJ5uyjLotuUlQNwJna2LyQMtcvua f9v1YIFai+7S2wbctdhse8S2K7/f7V8y2fqSNrVQMrhLO2MMGN5s+ZmpvgNqbLAT37ed /KVQuVJXNgtsf/Q4FWOL0IIKNbk/Td8aE4RP9WdJ1LGgv37k1cstHwZTKc2BUd7g6Ph6 7VVkWCWSAeA44cclapCPGKWUQJDEJQvf2YOc0/Dr/CXaigEU5Un9VEq5NpkY6ZuJmlJr YJdcU/fJ5V5a+1bDkODu5uyHGg01zWhIF8UaGd4oN8PcBYERVO7SzT5rfq0UdhMXF46R /6Yg==
X-Gm-Message-State: AOAM531NfswtP1jxQDkr07HHrFqPSWbbae77MfyWermNQT17egRpXdof 24lkmpEIaPAUwJ+a0dkH17OSTRyzpK2/m4Ho4lM=
X-Google-Smtp-Source: ABdhPJzNgn3l1iZfP+FVUVytDOo3vxkrmT20y5/gz/srFz1XuyaLIsbTFgVlaYADmOCVeOXnx7VFy0ujf9wG0Kso3Rk=
X-Received: by 2002:a05:6512:3f04:: with SMTP id y4mr23173398lfa.458.1620768649700; Tue, 11 May 2021 14:30:49 -0700 (PDT)
MIME-Version: 1.0
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com> <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz> <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com> <07FE2C2B-10C4-47B0-BFF7-AD8E980A2E26@hopcount.ca> <CAHbrMsB6qGs2QsvYMC9j2ahWAR80gdcsDbgihQiXYXG03OY9qQ@mail.gmail.com> <D72B8D52-50F8-457F-B123-D303F4865557@hopcount.ca> <CAHbrMsDzWjib5zfRpr3hJk4bjXjGAq9Z2pymPoLac9rJZPbWAQ@mail.gmail.com>
In-Reply-To: <CAHbrMsDzWjib5zfRpr3hJk4bjXjGAq9Z2pymPoLac9rJZPbWAQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 11 May 2021 14:30:37 -0700
Message-ID: <CAH1iCipSweK0nv06kLH0EJJD8Khn9kZTqjYLzSzN86mjr0ZQdA@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop <dnsop@ietf.org>, "libor.peltan" <libor.peltan@nic.cz>
Content-Type: multipart/alternative; boundary="000000000000a0eef905c2149b05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nGQZBzf1PcP6_rVLaq0OqGZFois>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 11 May 2021 21:31:02 -0000
On Tue, May 11, 2021 at 11:12 AM Ben Schwartz <bemasc= 40google.com@dmarc.ietf.org> wrote: > > > On Tue, May 11, 2021 at 10:32 AM Joe Abley <jabley@hopcount.ca> wrote: > >> On 11 May 2021, at 12:32, Ben Schwartz <bemasc@google.com> wrote: >> >> > On Tue, May 11, 2021 at 9:20 AM Joe Abley <jabley@hopcount.ca> wrote: >> >> On 11 May 2021, at 12:08, Ben Schwartz <bemasc= >> 40google.com@dmarc.ietf.org> wrote: >> >> .. >> >>> * It saves at least 11 bytes of overhead per parameter by avoiding >> repetition of >> >>> the name, type, class, TTL, and inter-pair binding ID. >> > >> > ... but it inflates response volume in the case where a separate >> SvcParams RRSet is able to be cached significantly longer than the SVCB >> RRSet. >> > >> > It sounds like you're proposing a design in which the information in >> one SVCB record is not just spread across multiple records in an RRSet, but >> actually across multiple RRSets. >> >> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB >> RR becomes a pointer to a second RRSet with a different RRType. So the >> SvcParams information is spread across multiple records in a a different >> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try >> again. >> >> Note that I'm not proposing a change to the spec, just illustrating that >> different design choices were possible that avoid the need for delimiters >> or escaping. >> > >> > This design choice, like many aspects of SVCB, was constrained by latency > and efficiency considerations. > I have a question (or maybe several) about the latency issue(s)... see below for context and the question(s). > > >> What are the concrete syntactical structure and the abstract conceptual >> structures? If those are terms of art I apologise; I'm not familiar with >> them. >> > > The concrete wire-format syntax is an octet sequence containing a > TargetName and some SvcParam key-value pairs. > > The abstract structure is a "binding" comprising a TargetName and a > key-value map that is associated with that TargetName. > Also related to the latency question(s) is (are) the questions about TargetName and associated values.... see below... > > What are you comparing the client implementation to in your final comment? >> What other design option was found to be more complex to implement on the >> client side? >> > > I was comparing it to designs where the TargetName and params are > separated into different RRs, or mixed into an RRSet with other bindings. > In such designs, the client must perform additional work to fetch, > associate, or reconstruct these different components that are encoded or > delivered separately but are only usable as a unit. > Here's where the related questions begin (and also include the client activities for fetching data, but also relate to publication of data being fetched....) I think there are design details (or maybe architecture is a better term) on the components of the binding, and the origin of those components, that is worth exploring in greater detail. I'll start with what I think are the relevant entities/parties, and how those relate to the HTTPS parts, and the DNS parts that support those (and for which the SVCB and HTTPS records are intending to improve). I believe the highest-level entities would be: - One (or more) Web hosting and/or CDN providers, which include some DNS components specific to the domain (the domain which is the owner name of the HTTPS record) - A DNS operator (either DNS hosting provider, or possibly the domain owner doing their own DNS) - From the perspective of a client, a DNS resolver (which may or may not have been upgraded to do anything special for handing of HTTPS or SVCB) - The client itself (web browser which is doing the appropriate queries including HTTPS or SVCB) If I understand things correctly, each Web hosting or CDN provider would supply the appropriate (corresponding) SvcParameters that are associated with the particular TargetName to the domain owner. Another way to put it is, the SvcParameters are actually bound to the TargetName, not the owner name of the HTTPS record, and the Web/CDN provider is (semantically speaking, not DNS-speaking) "authoritative" for those parameters. Is this accurate? So, the binding (of TargetName to SvcParams) is the thing that optimizes the HTTPS connections (e.g. H2/H3 etc), And, the placement of the binding parameters at the DNS record that references the TargetName, is an optimization to reduce DNS lookup latency. In the current design, the domain owner needs to, in effect, do a copy/paste from each Web/CDN providers' information into the domain owner's own DNS zone, including the TargetName and SvcParameters. The domain owner then would assign Priority values to each such record, thus prioritizing and/or balancing records provided by multiple Web/CDN providers. There is a potential for errors to be produced when the domain owner does this copy/paste. And the issue of managing any expansion of key,value pairs as different records in the RRset is the result of the copy/paste mechanism (i.e. copy/paste without having to understand or adjust any DNS record elements), and the potential for conflicting values from combining the records from multiple Web/CDN providers. I believe each TargetName still needs to be queried for A/AAAA records, although the "hints" from the SVCB/HTTPS records are (I believe) intended to allow the client to at least attempt to avoid the need for that query. The following would be very different from the existing SVCB/HTTPS proposal: - Publish SvcParameters as some sort of RRtype at (or below) each corresponding TargetName in the Web/CDN provider's own DNS zone - Or, have each Web/CDN provider publish a set of common parameters at some namespace within that Web/CDN providers DNS space, and have the SvcParams added to the HTTPS (or SVCB) record, by name rather than including the values. Either method (plus optional address hints) could reduce the complexity of what the domain owner would need to include, simplifying the parsing and allowing validation of names used (by doing DNS checks in addition to syntax checks). If the parameter sets were managed by the Web/CDN provider, and given a distinct DNS name (and referenced by name rather than value), the scalability of the bindings would likely improve, e.g. reference via CNAMEs (with the CNAME targets being long-lived and cacheable). This would also reduce or eliminate errors, by only having the SvcParams published by the party that is actually authoritative for them (i.e. the Web/CDN provider). The DNS latency issue is quite possibly a separate issue, depending on what the respective RTTs are for these different DNS relationships: - Client - Resolver (RTTc) - Resolver - Web/CDN DNS auth server (RTTw) - Resolver - Domain Owner DNS auth server (RTTd) I.e. if RTTc is small (local resolver near the client), and the cache is populated, I think the multiple-lookup thing becomes a non-issue. And, conversely, if RTTc is large, I think the wrong problem is being solved via adding SvcParams to the record in the domain owners' zone. I'm not sure if the latency changes much (or at all) if the resolver is HTTPS/SVCB-aware... These are observations and suggestions, hopefully helpful in keeping the conversation moving in a productive direction. Brian
- [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-0… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Wellington, Brian
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Petr Špaček
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Wellington, Brian
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Wellington, Brian
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-htt… Wellington, Brian
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tim Wicinski
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tom
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Pieter Lexis
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tim Wicinski
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Pieter Lexis
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Pieter Lexis
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Pieter Lexis
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Peter van Dijk
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Stephen Farrell
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ie… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… libor.peltan
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Vladimír Čunát
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draf… Wessels, Duane
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… libor.peltan
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draf… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Peter van Dijk
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… John Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Joe Abley
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… John R Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… libor.peltan
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… John R Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… John R Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… John Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Erik Nygren
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Erik Nygren
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tommy Pauly
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tommy Pauly
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Erik Nygren
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tommy Pauly
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Erik Nygren
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Martin Thomson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Martin Thomson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Wouters
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Martin Thomson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tim Wicinski
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Mark Andrews
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ralf Weber
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Eric Orth
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ralf Weber
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Tim Wicinski
- [DNSOP] Sub-field encoding scheme discussion (pos… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ralf Weber
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Dick Franks
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-sv… Ben Schwartz