Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

Ted Lemon <mellon@fugue.com> Fri, 18 August 2017 17:39 UTC

Return-Path: <mellon@fugue.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 90EB2132195 for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 CggyQqE7DNoI for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 10:39:38 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 A2A4E132063 for <dnsop@ietf.org>; Fri, 18 Aug 2017 10:39:38 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id z18so56608350qka.4 for <dnsop@ietf.org>; Fri, 18 Aug 2017 10:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LF2y7h1gfQaGwvxv0uIKCKaeuiGFIJ4qwoUJiTEf5U4=; b=kUA5MLR8C6cE4bDkVlyxFXiy/r/P1oeNDBBvCLUZECKlh8umkdKMG/Go6MCYXNbkgL ufNfbbazqQv1NBpCMrlr2EmqvvKtpGgFoN+ks+AQF+WbU1GUFtkRt2FxQaKz/n3Hbmcg s7PUCMPDS0bpVzAfavJDkqAVGUap/Jj5eNW4m+fhgcn/VLBLFryH+Ae6uyLfLOKEgw7m XaLI+S6s18hYQ15WSJ011FsXfYyZyNvqiDyWgzlkRvOF3efGzjl6oj1Sux9gz1F0/Kfc Umt088dIRG3jZkTa6ix1+BJr+Bo3GEBIKC6F2+BkYxdSNtqFegMA3B1q4rjZXFqAAvkQ k39A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LF2y7h1gfQaGwvxv0uIKCKaeuiGFIJ4qwoUJiTEf5U4=; b=IXZ52dmBxHkAhwgwHg/jtAj+hc3+NKdsWVOw62KdFDPxkW1zAtkZXCvhRv0afkJ7cn pmyy+9p021wWaxtQ9MtYHxoVSVPZ/D19uJ2acSdBQGQ0CFFm5Pkpgn5dEUr0X5CQpuft zPZkfnTSHfS2M5AR9n/QV1Tt/YCBRKv85fKb/8FiNo/5Nu6lq6uz67iX4Z0ie+7k4b4C q9eIg0ATqJ8JRPgXZqS8lYjl8lp6gB/XlnxItl+ypRID0Rd/Bt2V/72Sx3hLYHxnnTKq sHdPUle8EshMR5aOuh8CFlFb1z9pe7GFD0JDhnDwL1uZYQlTkhm8USzwxutrLh4bn/ZS jdZg==
X-Gm-Message-State: AHYfb5gdnAaq5Iga75TAQr2I2EjKB9EiA8Igin0A2ilSfieKaZ7q37rI KDgPb+hG91utd/Audzk4kw==
X-Received: by 10.55.97.3 with SMTP id v3mr13119780qkb.1.1503077977687; Fri, 18 Aug 2017 10:39:37 -0700 (PDT)
Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id 5sm3963339qkf.12.2017.08.18.10.39.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:39:36 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <C98DE50D-6E8F-4040-B6E2-45A1FA1B68A4@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31DCA852-B690-4160-A688-62941E614212"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 18 Aug 2017 13:39:35 -0400
In-Reply-To: <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz>
Cc: dnsop WG <dnsop@ietf.org>
To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> <b7ee0e88-62ff-0ada-1570-f77a90de1d84@nic.cz> <CAPt1N1=YKtvrNzy7ZEziqF79Kti1=0BwxFYw90fyk21-NSn_uQ@mail.gmail.com> <aa568b4f-9af4-ead7-3ddb-a245029af63c@nic.cz> <CAPt1N1k4ACH8fJUe-RZhtShboa+ihbnx7_r8s8+TD63bHB+Axw@mail.gmail.com> <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yN_-obO9nbp8yIZzOAGZ9sAkZ2k>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 18 Aug 2017 17:39:42 -0000

El 18 ag 2017, a les 11:12, Petr Špaček <petr.spacek@nic.cz> va escriure:
> My objections are in the end about engineering costs, which was nicely
> summarized by Paul Vixie in another thread (about SWILD, but applicable
> to session signaling as well):
> https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8 <https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8>
Paul's arguments aren't at all applicable here.   He's talking about having two different resource records that require detailed special handling; adding a new resource record that accomplishes what is accomplished by existing code in a different way produces a substantial increase in complexity not in the transport part of the DNS protocol, but in the semantics engine of your DNS cache.

> For me the major portion of cost does not come from features (like
> session management etc.) but from the *framework* needed to build them.
> This cost increase IMHO stems from fact that the framework (SS aka DNS
> control plane as you named it) does not build on existing and widely
> available components.

It's true, TLVs are quite innovative, and have never been used elsewhere.   ;-)

> I believe that added complexity is one of serious technical parameters
> and I was objecting to it 4 months ago already:
> https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg <https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg>
The problem is that you didn't say then, and you don't say now, why this supposed complexity is an important technical consideration.   And it's hard for me to see what the issue is.   Nobody has to support this; if you support it, it's because you want the features.   If you want the features, the complexity isn't really in the wire format serialization and deserialization—this are trivial.   The complexity is in, for example, implementing DNS Push through a DNS cache if you want to support it in that context.   I admit that this is complex, and I suspect that there will be little enthusiasm for doing it.   That's okay—it's actually not required that any cache implement DNS push in order for us to get the benefit of it.   But this complexity has nothing to do with the wire format.

The wire format itself is dead trivial.   If in fact you need to implement it, for example in wireshark, there is already code in wireshark for unpacking TLVs, so it's a very small update.   In comparison, adding some new EDNS0-style OPT RR actually require special custom code in wireshark, because the fields in the RR are given different meanings just for that one RR.   Of course, wireshark already (I assume) understands EDNS0, but we can't use EDNS0; if we add a new SSIG RR that looks like an OPT RR, we would be creating more work for wireshark hackers than if we just did what the current spec says to do.

> In general, as far as I can tell, this document gives no clear
> justification why it is a good idea to do it this way. What I really
> want, on the highest level, is to see a justification why it is a good
> idea *to not reuse and extend existing framework* like EDNS. We have not
> been told of the practical problems that preclude solutions which are
> closer to existing code, e.g. EDNS, which would lower the engineering
> costs for the whole ecosystem.

The most obvious practical problem is that, as I said above, adding another EDNS0-style option is more complex than using TLVs.   In addition, it consumes more packet space.   The actual format of the packet is less sensible.   The decode/encode logic is more complicated.   I don't know if you've written an EDNS0 decoder/encoder; I have.   It's not pretty.

Of course you already have one, and so do I; maybe we could reuse the code.   Doing so would also add complexity.   And the fact remains that it's a needlessly arcane data format.   The DNSIND (I think) working group settled on EDNS0 because they thought, as you did, that using something that looked like a DNS RR would make it more likely that things would work, but that turned out to be true—we had endless nightmares with middleboxes being confused by EDNS0.

The point being, EDNS0 was a design compromise based on assumptions that turned out not to be true.   I think if the working group had it to do over again and could see the future, they would have done something like session signaling, rather than adding the OPT RR.   Of course, that's just my opinion, but the reasoning is as valid now as it would have been then.

The rest of your comments appear to be rehashes of the same basic point, which boils down to "this is harder than that," with no actual technical basis for making such an assertion.

What I meant when I said "do you have any technical objections" was not "could you repeat for me in more detail the points you already made earlier about how if you were designing the enhancement, you would have done it differently."   That's basically what you've done here.   You would have done it differently.  That's fine, we're all reasonable people here, but we won't always agree on matters of taste.

But there's no technical objection here.   You've asked us to justify design decisions we've made (I use "we" loosely here, since I'm an end user of the document, not an author), but not provided any technical objection to those design decisions.   It's not good enough to say "I think that EDNS0 would be more right."  You need to actually say why TLVs are wrong (or, I suppose, why EDNS0 is more right).   You haven't done that.