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

Petr Špaček <petr.spacek@nic.cz> Thu, 27 April 2017 07:40 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 2702E128B44 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 00:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 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, URIBL_BLOCKED=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 6b3nJJY74Qh4 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 00:40:34 -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 C75AB128B37 for <dnsop@ietf.org>; Thu, 27 Apr 2017 00:40:33 -0700 (PDT)
Received: from [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a] (unknown [IPv6:2001:67c:1220:80c:9059:23a4:1953:3f7a]) by mail.nic.cz (Postfix) with ESMTPSA id 9DC9B62171 for <dnsop@ietf.org>; Thu, 27 Apr 2017 09:40:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1493278830; bh=LYL5HuHEPrV+LjioAgZ9mSY3Nz6kQGHZgkSsH2+Cz1U=; h=To:From:Date; b=V4zYfc6Sjin61Yq69h5PZjmpQRnIfRCFFYr0CbFbgCE9sfuJxmYhBcBlhRTFzygYg boRHEQbecPII9b0Bd6ePzDM5zofB1sPFpcoAdePEqY80MCkDhKDPOkoJ/3+XdwBCcd QpcUKhxsmMrN+YshGT3zbH4/ztfQ2n37B4oBwxtY=
To: dnsop@ietf.org
References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <A1F0201F-B081-4D36-A1A9-4811250CDB12@cisco.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <241ada25-4005-403f-0c1a-ce332a58e901@nic.cz>
Date: Thu, 27 Apr 2017 09:40:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <A1F0201F-B081-4D36-A1A9-4811250CDB12@cisco.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/XjbQlz5dPblzfGr0OBrr5afKBEg>
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: Thu, 27 Apr 2017 07:40:36 -0000

On 21.3.2017 20:34, Jan Komissar (jkomissa) wrote:
> Hi,
> 
> I have one comment for this draft. In Section 3.3 Message Format, I would prefer that if a Session Signaling message is received where any of the section count fields are not zero, the receiver MUST respond with an error code, e.g. FORMERR, but MUST NOT terminate the connection. My reason is that in order to ignore any non-zero count fields, the receiving software must have code to walk all the sections and this code would effectively be useless, but would still have to be properly maintained. The soft error response is required to make it possible for a future client to probe servers for support for a future Session Signaling based feature that uses the RR sections.

(Jan, thank you for reminding me to review this version!)

Other people already commented on semantics so I will focus on message
format:

My attempts to find reasoning for the new TLV format in archives did not
yield an elaborate explanation. Assuming I did not miss anything, it
seems to me that the current TLV format (placed outside of standard DNS
RR) is going to require brand new code and logic and makes imlementation
harder than necessary.

Every DNS server and resolver already has own code to parse DNS RRs do
various operations with them but this could cannot be reused for the
current TLV format.

It would be much easier to implement if we had new RRs like (e.g.)
"SSOP" and "SSMOD" and placed them inside additional section. We could
get the same semantics by creating a DNS message with all sections empty
except "SS*" RRs in additional section. Overhead on wire is negligible
and it makes implementation much easier and safer (because the normal RR
handling code is battle-tested already).

For these reasons I propose to move to standard RR format to enable code
re-use. Thank you for considering this.

Petr Špaček  @  CZ.NIC


> Jan.
> 
> 
> On 3/13/17, 7:44 PM, "DNSOP on behalf of internet-drafts@ietf.org" <dnsop-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:
> 
>     
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>     This draft is a work item of the Domain Name System Operations of the IETF.
>     
>             Title           : DNS Session Signaling
>             Authors         : Ray Bellis
>                               Stuart Cheshire
>                               John Dickinson
>                               Sara Dickinson
>                               Allison Mankin
>                               Tom Pusateri
>     	Filename        : draft-ietf-dnsop-session-signal-02.txt
>     	Pages           : 25
>     	Date            : 2017-03-13
>     
>     Abstract:
>        The EDNS(0) Extension Mechanism for DNS is explicitly defined to only
>        have "per-message" semantics.  This document defines a new Session
>        Signaling Opcode used to communicate persistent "per-session"
>        operations, expressed using type-length-value (TLV) syntax, and
>        defines an initial set of TLVs used to manage session timeouts and
>        termination.
>     
>     
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>     
>     There's also a htmlized version available at:
>     https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02
>     
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-02
>     
>     
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available at tools.ietf.org.
>     
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/