Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal

Stephane Bortzmeyer <> Wed, 07 February 2018 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74B3412D778; Wed, 7 Feb 2018 06:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pms7oezrV61B; Wed, 7 Feb 2018 06:22:04 -0800 (PST)
Received: from ( [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00C0F129C6E; Wed, 7 Feb 2018 06:22:03 -0800 (PST)
Received: from (localhost []) by (Postfix) with SMTP id 13F682820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: by (Postfix, from userid 500) id 0D12928226C; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: from ( [IPv6:2001:67c:2218:15::11]) by (Postfix) with ESMTP id 05D152820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id ECCBE6424E41; Wed, 7 Feb 2018 15:22:01 +0100 (CET)
Received: by (Postfix, from userid 1000) id DF186401C7; Wed, 7 Feb 2018 15:22:01 +0100 (CET)
Date: Wed, 7 Feb 2018 15:22:01 +0100
From: Stephane Bortzmeyer <>
To: tjw ietf <>
Cc: dnsop <>,,
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Operating-System: Debian GNU/Linux 9.3
X-Kernel: Linux 4.9.0-5-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.2.2
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2018.2.7.141515
Archived-At: <>
Subject: Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
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: Wed, 07 Feb 2018 14:22:08 -0000

On Thu, Feb 01, 2018 at 02:14:53PM -0500,
 tjw ietf <> wrote 
 a message of 55 lines which said:

> This starts a Working Group Last Call for draft-ietf-dnsop-session-signal

After reading -05 :

My personal feeling is that it is complicated, with a lot of
details. May be separating in two documents, one for the base DSO
concept and one for the standards TLV (with their detailed behavior)
would have been better.

There is a discussion about a possible Privacy section
<> for
which I suggest the following text:

The intention of this specification is to enable stateful information
(connection parameters and DNS data) directly related to the DSO
Session to be transmitted. This creates trackable state and prevents
queries from coming from successive privacy addresses, as could be the
case with regular DNS queries, for a privacy-conscious client. Before
using DSO (or any kind of long-lived DNS sessions), this consequence
should be taken into account. The risk is partially mitigated by using
encryption (which protects against sniffing by a third-party, but not
against logging by the server.)

The design of new TLV must also avoid adding any information that
could make this tracking easier.

Now, other points:

>   There are a myriad of other potential use cases for DSO given the
>   versatility and extensibility of this specification.

I don't really like this sort of sentence. Either we have ideas about
these potential use cases and we should write them down, or we don't
and we should avoid this sort of very general words (after all, human
imagination being what it is, we can be sure surprising use cases will
be found.)

>   If the RCODE is set to any value other than NOERROR (0) or DSONOTIMP
>   (tentatively 11), then the client should assume that the server does
>   not support DSO.

(Why "should" in lower case?) RFC 1035 being very clear that the rcode
from a non-DSO server must be NOTIMP (this is also said in section
4.2.1 of the draft), I suggest to change that to:

If the server does not handle DSO at all, it MUST reply with RCODE
NOTIMP (4) (this is from RFC 1035, section 4.1.1). Because not all
servers will be correct, if the client receives an answer with the
RCODE set to any value other than NOERROR (0) or DSONOTIMP
(tentatively 11), then the client should assume that the server does
not support DSO.

> DNS Stateful Operations uses "DSO request messages" and "DSO
> response messages".  DSO request messages are further subdivided
> into two variants, "acknowledged request messages" (which generate a
> corresponding response message) and "unacknowledged request
> messages" (which do not generate any corresponding response
> message).

It seems to me that the draft uses "response-requiring messages" as a
synonym of "acknowledged request messages" (and
"non-response-requiring messages" as a synonym of "unacknowledged
request messages"). If I'm correct, it would be better to state it
clearly in the terminology section.

> 7.1.  MESSAGE ID
> The table below illustrates the legal combinations:

Since there are only four combinations, I do not find this table useful.

Last, RFC 5226 (IANA considerations section) is now replaced by RFC 8126