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

Petr Špaček <petr.spacek@nic.cz> Tue, 18 July 2017 13:02 UTC

Return-Path: <petr.spacek@nic.cz>
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 36EB8131B51 for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 06:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 u-u4JNFs3FlQ for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 06:02:52 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EB7131B0A for <dnsop@ietf.org>; Tue, 18 Jul 2017 06:02:49 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5] (unknown [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5]) by mail.nic.cz (Postfix) with ESMTPSA id 1453B62284 for <dnsop@ietf.org>; Tue, 18 Jul 2017 15:02:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500382968; bh=xkXKlushCseWszEXM3iypty3EzfE98UK8VTXl7qg0o0=; h=To:From:Date; b=IYVSrRUJ+Hns5SodKqbcR2Db6t6EViNgiq66y9KmvseclKSG9QFUtaSBYvvEuAkSN AwsVaf1eLpFq6M9sa9mZIiKXXyABB91KXnfKX4U4zKRNKgO3PGuO54nLo1etd+YEEM abCj6r4Ov2zyyeoxOxjfNC/KAMUqB9j87r61a1Eg=
To: dnsop@ietf.org
References: <149912520399.16222.12738253224617069728@ietfa.amsl.com> <89e8d29c-1692-732c-df3b-8b7915415629@nic.cz> <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <77d0bc67-d6c3-de37-e88b-6b3612cf3d3e@nic.cz>
Date: Tue, 18 Jul 2017 15:02:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <5C0034DB-657E-4191-86CC-05B06F11EEAF@fugue.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ByGh-Fp2U9ISYg2T-mdgXSYlhvc>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.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: Tue, 18 Jul 2017 13:02:54 -0000

On 11.7.2017 13:23, Ted Lemon wrote:
> On Jul 11, 2017, at 3:17 AM, Petr Špaček <petr.spacek@nic.cz
> <mailto:petr.spacek@nic.cz>> wrote:
>> I feel that implications from switch to non-RR format are underestimated
>> and following e-mail attempts to explain why I believe it is a bad idea.
>> Please accept my apology for such long e-mail.
> 
> Petr, with all due respect, I did not see a counter-proposal here, and
> your comments seem to reflect a misunderstanding of what
> session-signaling is.
> 
> In fact, the opposite of what you said is true: if this were done as a
> normal query with EDNS0-like encapsulation, _then_ we would see
> problems, because session signaling messages would look more like DNS
> queries, and less like control messages.  This is not a desirable quality.
> 
> It's true that, for example, the DNS packet compression format would
> have to deal with this specially, but that would also be true if this
> were done EDNS0-style.   It's true that packet dumpers would have to
> deal with this specially, but that's also true if it's done EDNS0-style.
>   Etc.

Let me clarify that I'm not insisting specifically on EDNS0. From my
perspective anything which does not deviate from current wire format is
okay.


> It may be that there is a good point in your argument somewhere, but at
> the moment, I don't see one.   E.g., in your python example, yes, if
> this were an RR, not being able to plop it into your RR-handling switch
> would suck.   But it's not an RR, doesn't have the semantics of an RR,
> and if you plop it into your RR-handling switch, you're probably getting
> the semantics wrong.

This might be key to the the misunderstanding:

I'm not talking about semantics at all. What I object to is the proposed
wire format, not the semantics. The fact that bytes are stored in format
compatible with RR (RFC 1035 section 4.1.3) is not related to its semantics.


> So if you want to make this case, I think you need to be more specific
> about why this is a problem: when I think about how to implement this
> (which I have done, because I'm using it for dnssd), what you are
> advocating seems harder, not easier, than what is currently being proposed.
I'm trying to explain that deviance from RR format (RFC 1035 section
4.1.3) will force parties in the DNS ecosystem to implement support for
the new wire format even though they are not interested in session
signaling at all.

For a lot of cases it would be sufficient if SS data could be treated as
one of many "unknown RR types" (RFC 3597). For example tools for
statistics would work, the capture formats would not need special
extensions for SS, etc.

We can discuss this in depth during dnsop session today.

-- 
Petr Špaček  @  CZ.NIC