IETF Logo Mail Archive

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

Petr Špaček <petr.spacek@nic.cz> Fri, 21 July 2017 08: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 46B63131748 for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 01:02:56 -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 vozKtly6yHdM for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 01:02:55 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 DB52312EB2B for <dnsop@ietf.org>; Fri, 21 Jul 2017 01:02:54 -0700 (PDT)
Received: from [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a] (unknown [IPv6:2001:67c:370:128:8f23:502f:10bd:1a2a]) by mail.nic.cz (Postfix) with ESMTPSA id AE5DF61FF3 for <dnsop@ietf.org>; Fri, 21 Jul 2017 10:02:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500624172; bh=6Wz8Ln9BJhySoJO2loJqdY9OO5lZT/TxOfiYoaJcLGA=; h=To:From:Date; b=MuIyBM0gwCDH95skPagCLCaMLw+yyvNYe/NJCFR03joQuuTC8RPio6e9bprpc8NGx jHPDZTqc3faNr7VE1bc4OZXUvXl/ON8h3+p5Wl3qR+5JXKrgEGcho7Cdvo7eQn0pcf GDn64dMyVTWdRkGdRHd1p9GV8QZ7OfLIovZ6CDR8=
To: dnsop@ietf.org
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>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <b7ee0e88-62ff-0ada-1570-f77a90de1d84@nic.cz>
Date: Fri, 21 Jul 2017 10:02:52 +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: <20170720170907.gksdgic47juhbn7e@mx4.yitter.info>
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/DP9-3VhGwrEMPg9HYrAdixqlVyM>
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, 21 Jul 2017 08:02:56 -0000

On 20.7.2017 19:09, Andrew Sullivan wrote:
> On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
>>> But it's certainly another step along the way to DNSbis by accident.
>>
>> Would it be useful to make it not "by accident"?
> 
> Yes.  That was basically the point I was trying to make at the
> beginning of today's session, about overall analysis. 
> 
>  > b) make this draft DNS-SD only, so it can fast forward...
>>
> 
> I'm not keen on this.
> 
> 
>> c) use the changed paradigm to work on DNSbis without the accident part?

Yes please!

My main opposition comes from fact that current session signaling draft
"accidentaly" defines new protocol which is using the old DNS-RFC1035 as
"transport".

I would welcome DNSbis effort with clear cut. Here please note that
clear cut does not mean that RR format and data, for example, has to be
incompatible!

It is still possible to share big chunks of specifications (like RR
definitions, namespace, etc.) but define a DNSbis protocol which is
clearly distinguishable from the old DNS.

Petr Špaček  @  CZ.NIC

> I'm starting to wonder whether a bof is needed.  Maybe the IAB's
> workshop will produce some fruit?

v2.23.0 | Report a Bug | By Email