Re: [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 07 February 2018 14:22 UTC
Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3412D778; Wed, 7 Feb 2018 06:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pms7oezrV61B; Wed, 7 Feb 2018 06:22:04 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [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 ietfa.amsl.com (Postfix) with ESMTPS id 00C0F129C6E; Wed, 7 Feb 2018 06:22:03 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 13F682820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 0D12928226C; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 05D152820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id ECCBE6424E41; Wed, 7 Feb 2018 15:22:01 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id DF186401C7; Wed, 7 Feb 2018 15:22:01 +0100 (CET)
Date: Wed, 07 Feb 2018 15:22:01 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: tjw ietf <tjw.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>, dnssd@ietf.org, doh@ietf.org
Message-ID: <20180207142201.e3mobmoal43wkh3c@nic.fr>
References: <CADyWQ+GsU9dL8D58Eko0w9mVRMMTZ7f9NQKx3a0XS7oUGHjniQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADyWQ+GsU9dL8D58Eko0w9mVRMMTZ7f9NQKx3a0XS7oUGHjniQ@mail.gmail.com>
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
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.141515
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/NFtd5RGIJhbOnb4Q_dWLwfZmkYg>
Subject: Re: [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=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 <tjw.ietf@gmail.com> 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 <https://github.com/raybellis/draft-bellis-dnsop-session-signal/pull/36> 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
- [dnssd] Working Group Last Call - draft-ietf-dnso… tjw ietf
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Paul Hoffman
- Re: [dnssd] Working Group Last Call - draft-ietf-… Stephane Bortzmeyer
- Re: [dnssd] Working Group Last Call - draft-ietf-… Ted Lemon
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Jan Komissar (jkomissa)
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Ted Lemon
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Jan Komissar (jkomissa)
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Ted Lemon
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Jan Komissar (jkomissa)
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Ted Lemon
- Re: [dnssd] Working Group Last Call - draft-ietf-… David Schinazi
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Stuart Cheshire
- Re: [dnssd] [DNSOP] Working Group Last Call - dra… Ted Lemon