Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Brian Dickson <brian.peter.dickson@gmail.com> Mon, 17 May 2021 21:46 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 A905B3A4639 for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:46:30 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 hLFhKEgK5xW9 for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:46:28 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 55E383A4636 for <dnsop@ietf.org>; Mon, 17 May 2021 14:46:28 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id w4so9029440ljw.9 for <dnsop@ietf.org>; Mon, 17 May 2021 14:46:28 -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=os0NHabPem7HCZFdQRJ1qzIe943eOxhqXNsgpK5r40M=; b=FfiP7KD9H3EoOb4P4U0u22uBFPFI+yJiYaIm6L8VvC/wEULMGbdUStacbh6Qi21d5G r90UqRsoAnGA86j7K9CoGSmlYKRcA60urJCSStfnBj+RBeb6n0A6hQKeXYy4D0ySJCPg NuQZf1EcCFyphBEIWZS9TPDkPwObgG/CwqK//8J5oD/VaTRZ0kJfzsmAog/CKsbJDGtY IJ6zwGmDG0CbxM5V1Ic1lncIF6JbXODM5z3Yyj1N7VrjUNUQoXhpeZxJlPxTPeilR+CQ WLgJof3gSoOCttyn04pZthIleNBCiRtcreRDX/ZOXis6mJbzzo9i746rXsYjieFgkz/t d68Q==
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=os0NHabPem7HCZFdQRJ1qzIe943eOxhqXNsgpK5r40M=; b=iZqXFvEzUbpOU70yD9hZlr24rqqAdIG7Dajd3cCnu6Kv3YxnILoAdyNgWR6GHd5COh JyrBezVcvCA2UJeVEDNIwOCz+FJk7ZRecyUOlg7PXsvyze6OCY+kS8EzVeScDgBbPEDN v4sty/LoQqtJuV2O6GSfqs3Lv6TX2xtcu3WZrQUoVDriE+df/P/CfYJqxCptiSLc60LX LVu8N0hO1HtaIB0MjKoSP1a8XYM0gll8FJ2MMGsLWCQN+JXEzyerf5MxPGtRY9TY3U4b nFRTnh3d8lUB13Q7ej965Mw4mLf9THMOHvQ36bgYQlSLZNrmt5ZxrbrKN1/3IYzqLLVx gTig==
X-Gm-Message-State: AOAM530YAEgY6QvagXwwFm69KJjjBWaBeOF1ApawtluuZI9HyeM3+Vns thQAqbI40Ju+mdw2vtLa/lK6bSKI+NGbpXcvNVs=
X-Google-Smtp-Source: ABdhPJx6h4RQwpeO4JBh7hy6m3k72zU5tWqjEVTVEDAr5TVqeRP/cbYFn+8rLLHS3m9nShatR99nODqhUFDJ6VroeAE=
X-Received: by 2002:a2e:a492:: with SMTP id h18mr1151363lji.161.1621287986480; Mon, 17 May 2021 14:46:26 -0700 (PDT)
MIME-Version: 1.0
References: <7ADF1FB2-97A4-4C49-8F25-8BF03BE01640@hopcount.ca> <20210512213903.D5F1F7AA827@ary.qy> <CAMOjQcFJjcsvaREF0fr+2GTY4zTy5CxSxR16BEp=Nc-K9WJ0Tg@mail.gmail.com> <CAH1iCipAVKVCuH2ME=+YpeJyijrKCtzJaU3bRFyy1f48EB33iw@mail.gmail.com> <CAHbrMsCjWgV7nc575L_qdvr7HdoEVKqkXRwLdXA2L5NiCgdvwA@mail.gmail.com> <CAH1iCipW_-BSMQZ-S+m18pyzfxTGsCrmG9Pc-b35_VRiLhxh4w@mail.gmail.com> <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com> <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
In-Reply-To: <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 17 May 2021 14:46:13 -0700
Message-ID: <CAH1iCioNgQMjEZSeRdD3OmxPsboybF4XfcdwEC-hEjBLGA88XA@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>, Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/alternative; boundary="0000000000008361bd05c28d861b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9slecckYMr7LlcNTag_RjOkBlo0>
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: Mon, 17 May 2021 21:46:31 -0000
Here is a slightly deeper dive into this alternative scheme (for zone file/presentation and wire format), in terms of both the encoding, and the specification document itself (and as a result, the IANA components). I re-read (several times) the current -05 version of the draft. I found it difficult to follow and understand several aspects of the "automatically mandatory", "mandatory", and mandatory usage in the document, both syntactically and semantically. The actual binding specifications also were either incomplete or confusing, with respect to the mandatory/"mandatory" things. (Default values for alpn, plus the "alpn" parameter, and "no-default-alpn" were similarly a bit hard to follow, and/or hard to surmise from only the binding entry.) The list of parameters within a binding, versus across bindings, was also somewhat ambiguous, which for subsequent bindings (e.g. from new RFCs after this become an RFC) could be confusing or even result in conflicting bindings. Here are some specific suggestions, including incorporating the updated proposed encodings: - Use the term MTI (mandatory to implement) - MTI parameters would be "alpn", (maybe) "no-default-alpn", and (maybe) "port" - The IANA table in 14.3.2 really needs an MTI column in addition to the other columns - For each binding registry, an additional table column specific to that registry should be included/added: "non-negotiable", i.e. MTI for this binding. - Replace the "mandatory" thing, with an "optional" flag to be optionally appended to any parameters that are not "non-negotiable". - This also removes the need to have a sorted list of mandatory attributes - Each binding will have a list of non-negotiable attributes, which can be used for validating the "optional" flag on both the authority side and the client. - Any parameter that is not non-negotiable, but does not have the optional flag, must be supported by the client for the parent HTTPS/SVCB record to be accepted by the client. - The binding tables then become lists of parameter sub-types that the specific binding uses, marked as optional-allowed or non-negotiable. The binding table incorporates all the MTI sub-types as well. - The binding tables obviously still need default values (if appropriate), e.g. for ALPN. The HTTPS binding would then consist of: - Default ALPN of "http/1.1" - MTI of "alpn" - NN of "port" - NN of "no-default-alpn" - Optional of "ecn" - Optional of "ip4hint" - Optional of "ip6hint" And an HTTPS referenced record (included by reference from record with SvcPriority between 1 and 127), would have the following rules: - Any "optional" parameter MUST be implemented by the client, UNLESS the "optional" flag is present in the HTTPS referenced record - This rule applies to "ecn", "ip4hint", and "ip6hint" records (each has its own "optional" flag, and that flag is only applicable to the parameter associated with the main HTTPS record linking to the parameter). I'll follow up with examples, that correspond to the examples in the original document. Brian On Sat, May 15, 2021 at 12:48 PM Brian Dickson < brian.peter.dickson@gmail.com> wrote: > > > On Thu, May 13, 2021 at 10:25 AM Ben Schwartz <bemasc@google.com> wrote: > >> >> >> On Thu, May 13, 2021 at 12:51 AM Brian Dickson < >> brian.peter.dickson@gmail.com> wrote: >> >>> >>> >>> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <bemasc@google.com> wrote: >>> >>>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson < >>>> brian.peter.dickson@gmail.com> wrote: >>>> >>> >> Breaking the binding into pieces creates many new opportunities for >> error, such as having multiple TargetNames in a single binding. It >> corresponds to a multimap datastructure instead of a standard map. Every >> attribute of each binding would naturally be an unordered collection, which >> is a bad fit for attributes that are required to be singular, or an ordered >> list, or anything other than a set. >> >> Switching to a zone file format that is simpler to parse would go a long >>> way to improving those. >>> >> >> >> Considering alternative formats is an intriguing exercise, but I do not >> think it is likely to result in improvements to SVCB. >> > > So, my first alternative format (for splitting out key/value pairs) > involved adding another component to the record format, which (as you > noted) allowed for multiple instances of TargetName. > Here it is again for reference: > >> Encode everything using the following mechanism: >> Priority Enumeration Key Value >> One of the "Keys" would be Target, with a corresponding Value of FQDN. >> All of the records with the same value for "enumeration" belong together, >> and form a single SvcParameter list. >> For the AliasForm, both the Priority and Enumeration would be 0, and only >> a single Target,Value pair are permitted. >> To take one example from the draft, and re-encode it thusly: >> $ORIGIN svc.example. ; A hosting provider. >> pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..." >> HTTPS 2 . alpn=h2 ech="abc..." >> pool 300 IN A 192.0.2.2 >> AAAA 2001:db8::2 >> h3pool 300 IN A 192.0.2.3 >> AAAA 2001:db8::3 >> This would become (for brevity, encoding just a list of RDATA values for >> all of the "pool HTTPS" records): >> 1 1 target "h3pool" >> 1 1 alpn "h2,h3" >> 1 1 ech "123..." >> 2 2 target "." >> 2 2 alpn "h2" > > 2 2 ech "abc..." > > > So, taking your observations about TargetName into account, and borrowing > from the overloading of Priority to signal AliasMode, here's an alternative > that I think addresses most of the concerns. > Priority {AliasTarget | ServiceTarget | KeyName} > {ServiceBindingPriorityValue | Value} > where > Priority == 0 => AliasMode > Priority >0, <128 => ServiceMode > Priority > 128 => ServiceBinding key-value record > > The same example would be encoded (again with only RDATA values): > >> 1 target "h3pool" 128 > >> 128 alpn "h2,h3" > >> 128 ech "123..." > >> 2 target "." 129 > 129 alpn "h2" > 129 ech "abc..." > > The Priority values are sortable (as required), and sorting all the > records has the side-effect of grouping the key/value pairs. > If desired, the key/value pairs can be sorted by the first two fields > (priority and key) to check for uniqueness before use. > The look-up of keys and values, or the recombining into some arbitrary > structure (whatever the output of parsing the wire format from the current > proposal is), seems straightforward. > The parsing of each record's presentation (zone) format is as simple as > whatever each individual parameter's format requires/allows. > > And, there is no longer any ability to introduce duplicate target names in > a single record reconstruction, as the ServiceMode record is distinct from > the key/value set. > > If necessary, the presentation and wire formats for key/value records > could add an extra "." to avoid burning the Code Point already allocated. > That "." would simply be ignored, and add one byte (I think) to the wire > format, plus the other relative inefficiencies already noted. > > I think this is sufficiently different from the earlier encoding, to be > worth consideration. > > 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