[dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)

Ted Lemon <mellon@fugue.com> Tue, 18 July 2017 14:19 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D30412F3CB for <dnssd@ietfa.amsl.com>; Tue, 18 Jul 2017 07:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JxomWHElh1pI for <dnssd@ietfa.amsl.com>; Tue, 18 Jul 2017 07:19:14 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2CD12F280 for <dnssd@ietf.org>; Tue, 18 Jul 2017 07:19:14 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id o88so5819449pfk.3 for <dnssd@ietf.org>; Tue, 18 Jul 2017 07:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sbU2pn1bPZ5VAdGBrXAwhXMebNvH286pv0QD0pjMxH0=; b=wGCgiTCjhN6e56k1AfTPcwo4Ezxp36YpoSdmtM6EI5o/7w1VHhUy6cFu9rIiKYsWgI s0ljBZRHUXapNbq7wOjFIw/Zo8o8E0L2BgW2v4xUtymOzGL420NyqvDCY2GabTekMEbJ SSYcraSLTiPTFPItZAElSPgtKzBSn/aDI7bDKvZJpeCiIh4wffUPgArO7HFKqT6fKUPa dHJXhFndkRsO0qpe7bgOgXwDi9iULQ0tnglFLuKGSz4WuQ5QH0eNTvYrO37AoWuF0s05 PJjrFi00NkhhSrhxifOjoq/WcQQ+BnBs2MwU8c0RbALLv56fYdIIXPlHcwFNe52Ze1xU icFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sbU2pn1bPZ5VAdGBrXAwhXMebNvH286pv0QD0pjMxH0=; b=Hk/iOhNIXkWhc5nu6R1DpOUuxNa+KxPBPMFxXdMjkbVheK25CDhszmnAba9d3qs7bS FK8Xk3PVM+Dge/W5IQjAz/egucusmQpHEbOY40kzY8oJwybruIOMZqXDa1Brpuyf0593 YyGYEgtEubnNGoYFIP478gABQ7iw8STreU5VgdmlDZFj8DimkLhdIS0Y2ii/MoqlBQfD aNCPqJPPlJLfAr9m4pRa0oQHhLSDAPPy1Dh8rV52wKfCl+RRF7B1an9PgmHwLN9b/faj HMsK62VzDLbJaG35FdnMTFdoYgvNjE9HXjvJZ6CPjTc0nVn+/K/gjpwO9pdO4PgBYdx5 vB/A==
X-Gm-Message-State: AIVw112sNO595WJaH+Pu7V6r2LtQ5ZOdB5CCD3zAWQHVA0K16i5lcHvp AAQnNEFqXIJ/PwNP1BMQzNEZ6f7KS1JG
X-Received: by with SMTP id w15mr2036909pgo.22.1500387554002; Tue, 18 Jul 2017 07:19:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jul 2017 07:18:33 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 18 Jul 2017 16:18:33 +0200
Message-ID: <CAPt1N1khhGArF1CuubPJ=2=WCVX-7W8Kncs-s=Kk5XRjAT_ovw@mail.gmail.com>
To: dnssd@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1bdaa42eaddb05549833ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/7jeSIhXSrmWJKz_gYzdsy2_2CX8>
Subject: [dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)
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: Tue, 18 Jul 2017 14:19:16 -0000

I agreed to review this document before the next meeting, and it is still
(barely) before the next meeting, so here's my review:

In the abstract, paragraph 2, s/relation/relationship/ unless we are
talking about an rdbms. :)

In the introduction, point 1, "disclose its presence" seems like the wrong
thing to say, since merely sending a packet on the network discloses the
device's presence.   I think, possibly incorrectly, that what you mean here
is "reveal information that could be used to identify it."

Skipping to section 4, because I want to see if the document works without
sections 2 and 3:

In the first paragraph of section 4, you don't say which device serves as a
server and which as a client.   Presumably the client is the one where the
user initiates the pairing, which is arbitrary and doesn't really matter?
Might be worth saying so explicitly.

In 4.1, the QR code scanning seems like it's a separate protocol.   Might
be less confusing to leave it out of this doc and do a follow-on doc that
describes how to do it in more detail.   It feels like a distraction.
This is true as QR codes come up later in the discussion.

Also in 4.1, it might be good to go into a bit more detail about the
service records that should be published.   I think that this may be
incomplete.   If you want, I can look into this in more detail and propose
text if I still think it's a problem.   E.g., I assume class and weight in
the SRV record are 0 and are ignored by the client.   I assume that the
text record is empty.   It would be good to say this, and to say that the
client ignores these fields.   This observation may also apply to the
private service discovery document--I didn't think of this when I was
reviewing it.

p. 18, first full paragraph, SHOULD .. MAY doesn't make sense.   Either
this is important, or it's not.   If it's important, then you need to give
the implementer clear guidance on what to do if the API doesn't let them
figure out which hash algorithm was used.   The MAY seems content-free.   I
would think you would want "SHOULD/MUST use the strongest mutually
available hash algorithm."   Personally, I'd just say MUST, and if the API
doesn't support this, they need to use a different API.  That way you are
trusting that the infrastructure is going to make the best decision
possible based on the situation at the time that software was released,
rather than hard-coding a suggestion for a hash that we think is strong now
but may not think is strong later.

In the second paragraph of section 5, time frames are discussed in very
vague terms.   It might be a good idea to be less vague.   If we don't know
how to be less vague, I don't really know how to implement this.

I haven't tried to implement this, so I don't know for sure if this is
true, but based on reading the document I believe I could implement it, and
it's not hard to implement.   I think the additional clarity I asked for
above in section 4.1 would make interop more likely, but as a potential
implementer I would make the assumptions I suggested requiring, and I think
that would work.

Going back:

I now definitely agree with the suggestion to separate this into two
drafts.   The document without sections 2&3 gives enough information to
implement, and there is enough motivational information in the introduction
(I haven't read sections 2&3 yet).   Having just scrolled back over
sections 2&3, I think leaving these in the document will discourage
potential implementers.

[actually, I'm just going to send this in two parts--I might not get to the
rest of the review for a while, and hopefully this part is useful.]