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

"Jan Komissar (jkomissa)" <> Tue, 21 March 2017 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55D4A128BB6 for <>; Tue, 21 Mar 2017 12:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.022
X-Spam-Status: No, score=-14.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CCFBdZFbLF-a for <>; Tue, 21 Mar 2017 12:34:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E96F12894A for <>; Tue, 21 Mar 2017 12:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3712; q=dns/txt; s=iport; t=1490124877; x=1491334477; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FQnEJNSbQexdJ+5Bv14YJpz5vJQcdCIH3WWAHMfxJno=; b=JMqDDPNjfvzTjJ+EXgdkvBkBiT8o++96aoNVFfb17mIUpV2Udk10FM/Q x9XxvcSVvQpK6U+QyhQ5zK9GiHDRSYAonPFA6yEnv8aRYzqnVq8jMZSiN lIC5/V6/ZWmuUacbHSpXPQrepyBhYwpSEU3FAHcHxquPjZQq2b612y0zE o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,200,1486425600"; d="scan'208";a="223164294"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 19:34:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2LJYaT1017828 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Tue, 21 Mar 2017 19:34:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 14:34:35 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 14:34:35 -0500
From: "Jan Komissar (jkomissa)" <>
To: "" <>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
Thread-Index: AQHSnFRqXQoq72xJBUue7Hcntp9h96GfzHKA
Date: Tue, 21 Mar 2017 19:34:35 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Mar 2017 19:34:39 -0000


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.


On 3/13/17, 7:44 PM, "DNSOP on behalf of" < on behalf of> 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
       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
    The IETF datatracker status page for this draft is:
    There's also a htmlized version available at:
    A diff from the previous version is available at:
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at
    Internet-Drafts are also available by anonymous FTP at:
    DNSOP mailing list