Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Ben Schwartz <bemasc@google.com> Wed, 21 April 2021 19:51 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 163B83A3466 for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 12:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yot8_CQ6qbQT for <dnsop@ietfa.amsl.com>; Wed, 21 Apr 2021 12:51:20 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 396473A346A for <dnsop@ietf.org>; Wed, 21 Apr 2021 12:51:20 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id g9so26505521wrx.0 for <dnsop@ietf.org>; Wed, 21 Apr 2021 12:51:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G62+BTKHtRiv+MlvIjwj79Y+0+161X06E63AL4JJseM=; b=sre6bq2Vh0EmeY7GVQkZz1vTsygbMC6cMDZA/KL0G69Ui/UpXtaqU54/J3xKcCx27z 9yDeMyKfgqK0iT+43rRn6NGqs2HiLY0K1UzMktjlp7Q5Z4ONqR8GG/4CBWiNTynyUlCa kFbCLxYw+NCQT6XwV8FJzT4txDqINE9Igcwd4ejFVRkCTPL+5jiGJEwDjyPmK6Y2RRdY QXOnxSeLVp7onNeUbmoFWlbe+MHMalY2S85Yarsmq00xtNXqes1ePs6/qoY1Tj7nQzEL gQSDbeEV3Y6WyNwszf5rf61VfTdLrt8gW5CIqBeqHBAuSF9tjroRV7mSLnXwf7Zwd55r kpqA==
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=G62+BTKHtRiv+MlvIjwj79Y+0+161X06E63AL4JJseM=; b=NLXzkYId0i4amO4y+uPsUQmtb/wpvXxIfNHMVLHIdZejis+YE0Ow0PycfrDOsBxP2r hFm1DOKxeFKHbrudYN/FWnnB73oS8LIaBBO/TKX99vRbA48HI26Z7tXB4UAeNtXAP+EP rTrOXtxvR+sLWC5yWBUjsr6pRZYNjrReHgq26IYEBB38h8itI0tZBr3sVXhpj1rWrJUE dGlrcpsqrti9e3UGgY4o9J03kwL+J2zDPuPupnaSn2TpGBxEeLZrVRa8EzpU1mevAZLV cOltF5MruYvwP9IWRbaFCJ08oE/5JNhYRrAok9URgw0SijRiTn35BSFI74oOOGmOhNUY ruaw==
X-Gm-Message-State: AOAM530gVJRaV8jRI88HtAw6hSCvuVHFrdJzE+er5HtAVDZ6FYkoZw5D eat3uDzLJJR6VZqqohIcpz+6yMyJSbVO+3XgHej69w==
X-Google-Smtp-Source: ABdhPJwwcMmAQcttUfN+rEVIsapCh0QSciQ4tDf4I2QS2Rl28Yo4iBsFM1nGaWmSNyLGtuMXELe2uxrawNxGA86xUso=
X-Received: by 2002:a5d:640e:: with SMTP id z14mr29039298wru.258.1619034673141; Wed, 21 Apr 2021 12:51:13 -0700 (PDT)
MIME-Version: 1.0
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com> <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com> <CAHbrMsDaqrQ+XDO4z395tC_yOH4MBH8OmoH8zTXWEHfcDC1+Ew@mail.gmail.com> <6245BB4F-4E2F-435F-ABC0-18C0420C8541@akamai.com> <CAHbrMsDGq0usDiqr0HtbFCR4Y8swtyv_0i7UOFf=C_ExW+0FNQ@mail.gmail.com> <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com>
In-Reply-To: <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 21 Apr 2021 15:51:01 -0400
Message-ID: <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@mail.gmail.com>
To: "Wellington, Brian" <bwelling=40akamai.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000009a209a05c080e2f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/i8Cs-7dzH_8rLcCkkf-Ls0CO9XU>
Subject: Re: [DNSOP] 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: Wed, 21 Apr 2021 19:51:23 -0000
Here's a proposed text change that I hope can satisfy both of our requirements: https://github.com/MikeBishop/dns-alt-svc/pull/319 The key sentence is: To ensure compatibility with complex SvcParam specifications, recursive resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT reject the record on this basis unless a value is obviously invalid. On Wed, Apr 21, 2021 at 3:18 PM Wellington, Brian <bwelling= 40akamai.com@dmarc.ietf.org> wrote: > > > On Apr 21, 2021, at 11:58 AM, Ben Schwartz < > bemasc=40google.com@dmarc.ietf.org> wrote: > > On Wed, Apr 21, 2021 at 1:24 PM Wellington, Brian <bwelling= > 40akamai.com@dmarc.ietf.org> wrote: > >> Yes, I think that sentence should be changed. I’d suggest removing the >> "malformed SvcParamValues” part, but others may disagree. >> >> I agree that a URL is a tricky case. The spec writer might not want to >> include an ABNF representation of a valid URL, because implementors would >> likely want to use existing facilities to parse URLs, which are likely not >> consistent. In that case, though, I would expect the spec to indicate that >> the field is a bytestring, and the resolver to be able to that. The fact >> that it’s a URL is something that the client should be checking. >> > > But surely by this standard all fields are bytestrings? > > > They’re all sequences of bytes, sure. But all of the defined parameters > do have syntactic structure, and resolvers should be allowed to do the same > level of syntactic checking for SVCB/HTTPS records as they do for records > of other types. If there’s checking which is clearly out of the scope of > the document (like URL validation), that is fundamentally different than > checks like “the IPv6 address is 16 bytes”. > > > For the existing parameters, there are checks that can (and should) be >> made; that IPv4 addresses, IPv6 addresses, and ports are of appropriate >> length, that the ALPN field has the right length prefix, and that the >> mandatory field is ordered and has a valid length. >> >> There are also checks which are not specified, and which a client may >> want to do, but are not part of the record format itself. I wouldn’t >> expect a recursive resolver to reject a record containing an ipv4hint with >> the address 255.255.255.255, but that doesn’t mean that a client should try >> to connect to it. >> > > It sounds like you are suggesting that we distinguish between "how the > resolver should parse the value" and "how the client should parse the > value" ... but the value is meaningless to the resolver, so there is no > particular sense in which the resolver should parse it. This is not like > JSON, where an intermediary might check that the value of the "url" key is > a string, without checking whether it is a valid URL. All SvcParamValues > are opaque bytestrings unless you know how to parse them. > > > Again, there is a difference between syntax and semantics. The resolver > should be allowed to check that something conforms to the syntax specified > in the spec, even if it doesn’t use the value. > > Resolvers do not use the contents of most DNS record types, other than the > ones which are used part of the DNS protocol itself (NS, A, AAAA, and the > DNSSEC records). That does not mean that it shouldn’t check the formats of > other known records when possible. > > > >> I do not think that it should be required that a resolver is able to >> convey malformed records, where malformed is (only) referring to the >> syntactic content. That’s not how resolvers work for other types; no >> resolvers have options to allow 5 byte A records. >> > > Similarly, there's no requirement here that resolvers be able to convey a > syntactically invalid SvcParams structure (i.e. truncated TLV). The > requirement is that resolvers are, in general, able to convey records even > if a SvcParamValue does not appear to be valid according to the key's > specification. This is particularly relevant for multipurpose codebases > that can act as both recursive and authoritative (or client). Such > codebases must contain full SvcParam validation logic for all recognized > SvcParamKeys, but they must be able to bypass it in recursive mode to avoid > ossification. > > > This is absolutely not true. Once the format of an rdata type (or a > subtype, like an SVCB parameter) is defined, it must not change. The > authors of this spec surely know this, as there was a lot of discussion > about the incompatibility of the echconfig->ech change, and how something > like this could never happen in a standardized type. A correctly > implemented resolver should never reject a valid parameter as invalid, and > if there is a need to change what the definition of a valid parameter is, > that requires defining a new parameter type. > > This is not a requirement that resolvers always pass through these invalid > values, and in many cases (e.g. "port") the validation is sufficiently > trivial that enforcing it poses minimal compatibility risk. However, I > think this is worth highlighting because, in my own implementation, it was > easiest to enforce full validation for all recognized keys (present and > future) during recursive resolution, and some extra effort was required to > make sure that invalid values could pass through. > > > It’s a requirement that recursive resolvers introduce new behavior to > allow the avoidance of format validation for SVCB records. You’re free to > implement that in your own code, but it’s an onerous requirement for other > implementors. > > Changing the text to: > > Recursive resolvers MUST be able to convey SVCB records with unrecognized > SvcParamKeys, and > MAY be able to convey SVCB records with malformed SvcParamValues. > > would be fine with me, and I’d ignore the MAY part. > > Brian > > On Apr 21, 2021, at 10:00 AM, Ben Schwartz < >> bemasc=40google.com@dmarc.ietf.org> wrote: >> >> On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian <bwelling= >> 40akamai.com@dmarc.ietf.org> wrote: >> >>> I’m not a fan of the new text in section 4.3: >>> >>> Recursive resolvers MUST be able to convey SVCB records >>> with unrecognized SvcParamKeys or malformed SvcParamValues. >>> >>> >>> It is perfectly reasonable for a recursive resolver to reject any >>> malformed DNS record. There’s a significant difference between “malformed” >>> and “unknown”. A recursive resolver should definitely allow records with >>> unknown SvcParamKeys, but if the format of a record is known, a resolver >>> should be allowed (encouraged, in fact) to check that it conforms to that >>> format. >>> >> >> The concern here was about differing interpretations of future >> standards. For example, if some SvcParamValue is defined as a URL (for >> some future key), implementations are likely to disagree about whether >> certain bytestrings are valid URLs. (There are several definitions and a >> zillion edge cases.) The resolver has no use for these values, so the most >> compatible behavior is to treat them as opaque bytestrings. >> >> We very deliberately chose the phrase "MUST be able to convey" to >> recognize that resolvers might be configured not to convey a record with a >> malformed value, but it should be possible. >> >> Do you think we should change this sentence? >> >> >> >
- [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