Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt

Ted Lemon <> Mon, 16 July 2018 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E630A130F25 for <>; Sun, 15 Jul 2018 19:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 IRiKntlUmbvJ for <>; Sun, 15 Jul 2018 19:31:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A0F9130E72 for <>; Sun, 15 Jul 2018 19:31:50 -0700 (PDT)
Received: by with SMTP id h2-v6so16949621itj.1 for <>; Sun, 15 Jul 2018 19:31:50 -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 :cc; bh=vt49laeriP4kUgUHDRwEpzlq+l6jT/KLki4aCxyTa2I=; b=ZxMQMj8ZzGV8pR70dWqgVplNOkxPi+OSqGSernEWuWhPoI4wqi6h6d9yVw9cpLmNel rockzOizTfbVlx1n1w/Jk2v9nDZ438OWTd2qeNazFOpGKH2Vq5/ee9IPZbVgzCtkZ3aa j8tEsblgnH5YQy98U0ASBLkfsYIrZTw6VXg8K4rvh6FCr/zdrOoAVNsi97LLSgCXc4nU QdiWFJpxxvSB10akoX418VxBKuw7wINEF/v0J7Go63gRzqEtLZEG8+GfevrxwJxBNOPd W5sBYacgW0X3bpSPVOm5m8mGewVro14FwYZipWNNwAaC+XP+YA7XRa2rpYnJoezcPPRJ 5utQ==
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:cc; bh=vt49laeriP4kUgUHDRwEpzlq+l6jT/KLki4aCxyTa2I=; b=qy+qld/hVPmjEba4MWjCgWR8Kyzmt8UZGhfGl64hAMufNpVX797ogmbfe2bkXMM0Qt hMAvMr+jX24Syznv9R24IrSjzQe2b8V2Yq3uDDX1kcAbeq6FF+FWV16+HNz6so7k3nLv zzpL+ZFxXyYXYodRReVYmUj5cba13tMHFegahlyX/m8+JG0JKuKWtXgPNJIQrGCTvlp1 NTuKVXM2j2zKYYC3NKNXQrQWJd9UjBK++JJJq7iryvRez17pQkmuVBO/9+6luw1ReTMu GvpB925IIhcW5QYkGUrC8tt7/v41re4WLA67D3Sldlc26uSqRGL/DgNsJVoPNn5mr+/Q SIeA==
X-Gm-Message-State: AOUpUlH70wf1u8WEJTIDndL+jpeWJ7eBkSAxijDHn84OMJQxEOALjV4f jJ6wQNmobPF6u2du0RvkqEE0HEkqrmsRHYzl+zgrAmAk
X-Google-Smtp-Source: AAOMgpcq7Dh5YkUJFT0YLixNkz7JNeyd8XRCKTVJPOsYTMjhOdKbKEqVZdvBIQwUxzC955sU1hIMVUv0CEJ7V0zZjOk=
X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr12260700jad.38.1531708309584; Sun, 15 Jul 2018 19:31:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 19:31:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Ted Lemon <>
Date: Sun, 15 Jul 2018 22:31:09 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="000000000000b1574a057114a1fc"
Archived-At: <>
Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt
X-Mailman-Version: 2.1.27
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: Mon, 16 Jul 2018 02:31:53 -0000

Here are some proposed fixes to the issues you've raised:

On Sun, Jul 15, 2018 at 10:18 PM, Ted Lemon <> wrote:

> On Sun, Jul 15, 2018 at 9:55 PM, Tom Pusateri <> wrote:
>> Some quick feedback on the latest version:
> Thanks! :)
>> 1. You reference mDNS but don’t define it as multicast DNS or reference
>> RFC 6762.
> We do reference RFC6762 in the introduction, but you're right that we
> don't introduce the term properly.
>> 2. Section 2, second paragraph, you mention registering with the default
>> registration domain ("dr._dns-sd._udp”).
>>         a. You could add Section 11 to the RFC 6763 reference.
> Good point, thanks.
>>         b. You don’t specify if you should use the .local domain or
>> another domain. If it’s another domain, how do you find that domain?
> We specify that you should discover the default registration domain and
> use that.   It sounds like this wasn't sufficiently clear, though.  :)
>>         c. Why do you recommend always using the default registration
>> domain? Couldn’t you get the list of registration domains
>> ("r._dns-sd._udp”) and pick one of those?
> This is an automatic protocol, so that would have to be configured.   Once
> it has to be configured, then it doesn't matter whether it uses the list of
> registration domains or not, although certainly one way to make this work
> would be to have a UI that presents that list and allows the user to choose
> one entry.
>> 3. It’s not clear to me from the document about the TTL values. The life
>> of the registration is handled by the Update Lease Time and the Instance
>> Lease Time. Therefore, I think the document is saying (after talking to
>> Stuart) that the TTL in the registration is the one the client wants the
>> server to use in responses. But the server is keeping the registration for
>> longer than the TTL based on the EDNS(0) Update Lease Option values.
> Yes, TTL and leases are completely different things.
>> So does the server start the TTL countdown on the first response and then
>> subsequent responses use the decrementing TTL until it times out and then
>> the server resets it to the TTL it received in the register on the next
>> response? This is confusing to me even after talking to Stuart so I”m
>> probably just missing something.
> TTLs are used by caches.   The server always sends the same TTL.
>> 4. Section 3 (security considerations)
>> You limit the scope of this to within an administrative domain limiting
>> it’s applicability but nowhere else in the document do you convey this. For
>> most of the document, the reader may assume that registrations can be done
>> from anywhere, may wonder why they aren’t encrypted, and then only see in
>> the security section that this is really made for IoT devices and in the
>> home.
>> I think the name of the protocol should reflect this limited scope
>> instead of using a generic name like Service Registration Protocol since it
>> isn’t designed to be used as a generic unicast service registration
>> protocol. Maybe something like Local Service Registration Protocol or Site
>> Service Registration Protocol or Constrained Service Registration Protocol
>> or something better than I can’t think of right now,
> I don't see the point in this.   If we want to make it possible to
> register services from outside of the administrative domain, we can add an
> extension to do that, but it doesn't really make sense to have a service
> registration protocol that takes the place of an administrator, but that
> spans administrative domains.   If we had an authenticated service
> registration protocol, it would just be this protocol plus some additional
> stuff to allow enrolled devices to register when not local.   So I think
> making the base spec have a name that is limiting in this way would send
> exactly the wrong message.