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

Ted Lemon <> Tue, 18 July 2017 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BB8312FEEB for <>; Tue, 18 Jul 2017 09:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ltvO8b1QjWP for <>; Tue, 18 Jul 2017 09:57:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94C5E12EC37 for <>; Tue, 18 Jul 2017 09:57:36 -0700 (PDT)
Received: by with SMTP id v190so15906564pgv.2 for <>; Tue, 18 Jul 2017 09:57:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qPXHDyOlwbp7/GtjnPyQPMXJj8ZCjD3lN1YAwwApxEw=; b=ItWSokwCLhQhzf09GKogvj935i6oeuNgc2ZOOaAjWTggvcgm+H9kEyoBI85gjBjSUy G+PQICCM0Jno4yXH9kKp6EtruwvNLHNDD95u7UC1Rw009rPLY9ij9H18HzV/UcTl8GOP Q2ya1QlmeqBZrVJlWQSnqKYd9QjvQarbN1cp42U5lMMlU7PFOSt/aJHOyo7qPWCzMD/D y3TJrdwLJMxbeNMilj824NuKGL2CZH8Zs5wwCHov5T3ypQk/2nIfjykCG30xKJnPPNLp yHIaK+GZ9GaI9384Xvslb9JDEcI5zLFbW6+JbaSB0+PA1P8NTP8MCUQJBvZl+1yr5SvH KMHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qPXHDyOlwbp7/GtjnPyQPMXJj8ZCjD3lN1YAwwApxEw=; b=dcnXGnRwzX9ZTTHUoy9SR6RD+OPWbrluJy7rIPpn4W+j7p+uiiRJal9XvXQQbM9p3b NAVPeTyrhHaFBc5UUuyNOPg2qB6L/zQ7cUoHe6+ooe1AW2a1+be4su0zGjoAaPm/gvbj P85mHW5/cnL9OyZQe5jiEKrl21MtFw9yn/ftBJw/mub85xybCW+XCcLWPmr3IGgbeLrC bYdyYruZE7V8WjbhVHbfI+6NPAA0qh4UgJsCyF2fM3aEBeoydszMAvBXr9nOTMCnWAe3 JDcrA1XPzw6drF/mKWn9oePRHrlbZ6etbXqH/BOpBMYpBd5Wd8pjVnw/bfmHTco6LC6k fzbg==
X-Gm-Message-State: AIVw111Qh8mvi9pP9An4pxYLqphJqtlF6JkXgFF+1KnHo/q82K7thA9Q TIGcdAgbFg6xGJmxkKO4WemG2l5rhwv6
X-Received: by with SMTP id 1mr2823272ply.103.1500397056065; Tue, 18 Jul 2017 09:57:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jul 2017 09:56:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Ted Lemon <>
Date: Tue, 18 Jul 2017 18:56:55 +0200
Message-ID: <>
Content-Type: multipart/alternative; boundary="94eb2c1194ae8c96ec05549a6921"
Archived-At: <>
Subject: Re: [dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 16:57:42 -0000

Oh, and the only issue I noticed in sections 2 and 3 is that there's at
least one use of the word "relation" where the word "relationship" is
what's meant.

On Tue, Jul 18, 2017 at 6:55 PM, Ted Lemon <> wrote:

> Okay, having now read sections 2 and 3, I still believe they should be in
> a separate document.   This isn't just because of what I said in the
> previous message, which I still think is true.   It's also that this
> document actually will serve as a useful jumping-off point for further work
> on authentication in homenet.   So separating out the informational portion
> of the document from the technical specification makes both documents more
> useful (at least, selfishly, to me).
> On Tue, Jul 18, 2017 at 4:18 PM, Ted Lemon <> wrote:
>> 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.]