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

Tom Pusateri <pusateri@bangj.com> Fri, 18 August 2017 20:46 UTC

Return-Path: <pusateri@bangj.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 A9C5213234E for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 13:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qjEO-XhPDXlR for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 13:46:50 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DC6132332 for <dnsop@ietf.org>; Fri, 18 Aug 2017 13:46:50 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.249.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 396C925B83; Fri, 18 Aug 2017 16:41:21 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <041D0F94-7FBC-4F7E-B200-6A5EECB8776F@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_258E14C8-0ADE-442D-B6FB-46E9CA056A1E"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 18 Aug 2017 16:46:48 -0400
In-Reply-To: <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz>
Cc: Ted Lemon <mellon@fugue.com>, 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/Kgxs_xLiGwCD2JhavRP4dM5QKzQ>
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 20:46:53 -0000

> On Aug 18, 2017, at 11:12 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
> 
> We can certainly call TLVs "extension" but renaming it does not remove
> the fundamental problem:
> TLVs are largely incompatible with the code we already have widely
> implemented and deployed everywhere in all the DNS implementations and
> tools. As a consequence, it is increasing engineering cost for all
> involved parties.
> 

There were two main reasons we chose to use TLVs instead of the EDNS(0) RR format for Session Signaling (soon to be called DNS Stateful Operations) and it was quite intentional:

1. Given the fact that we were using a new Opcode, we had the opportunity to change the packet format for the better (at the suggestion of Mark Andrews). There has been a lot of people in DNSOP saying EDNS(0) OPT RRs were a mistake. To be fair, some people like it or are agnostic but we’ve heard more complaints than support. Using a new Opcode created an unusual and infrequent opportunity to switch to TLVs without a backlash since all the code would be doing new things.

2. Since EDNS(0) is per packet and not per session, and Session Signaling is defined per session over a reliable, ordered transport, we think it will be less confusing and simpler for implementors to have separate code to deal with session semantics over the existing per packet datagram semantics that don’t mean the same thing.

* When I say we, I am saying what I understand to be the consensus of the authors. I don’t mean to speak directly for the other authors and I will let them correct me if there is disagreement that I am not aware of.

Thanks,
Tom