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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34696130E40 for <>; Sun, 15 Jul 2018 19:19:35 -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 C79z9cgDzqsb for <>; Sun, 15 Jul 2018 19:19:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 491A8130DEF for <>; Sun, 15 Jul 2018 19:19:32 -0700 (PDT)
Received: by with SMTP id 72-v6so2558853itw.3 for <>; Sun, 15 Jul 2018 19:19:32 -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=/6fMlvdUt8HkTv/OoK7jT77CjjY0uDnz2klj+O1+Mks=; b=f4TVC9NdJqXmz2OeB5zqHVBOy5l/PSBoOmdSjAki7qEkmw2ZmSMKzfOOYQ9dlRR8Ue 5CrpeyvorSb+Qbxys+usKtdUw4yImyWKvrF308DIiwaH8N4Dx6gsnoL/W+HnbpSJmjTl ZUjIzIOC7TioLPMh4iLd8t1wLX1t1KdPw6iAiQl/TXhfGZS4NztcnFU9NAUtZoXSAP9I UTM890hRy6Dxp4ne+7LK1S3XeYywQVhCS5mp7CjzGwkp3wCMLoAqfBlHvCG3khIJmUyp AI2eGWuihKjKFw0I1ro6KA/sgKAV/CbRZ4MrDAxptqRx62Opg+Znx0GgFg12nQePLyxe 61NA==
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=/6fMlvdUt8HkTv/OoK7jT77CjjY0uDnz2klj+O1+Mks=; b=CPDzI0JaKHc5WRuDMJRaSmloqrZQoCbWn+/XwY/xQBUnsX9KvRgvEnprTUPR18pIS9 808yZipcSd1bExMSrzIMQ2GeBvdL+YIgtkgz5t+/UgJlOhPTY2EAOS8GOpMf1sLAwNfp R7lOkrB8hHlh6JvNVtO/7jYVoVYib2VZk/6XibEKPu7aFx1faewpIU1VQGv0NvZdaoVZ BtQGQ4SAXJntyjNiMQIpP+qBRP/Gh77MZrZluIYG1bWR5bR19Nadb1wtRNw+OkN5xc3y PsAP9PQ/xCbWonp4QEAG1eLj/0bz5lh+T659XRLvin0QMHwhKMqhWA+/TDQ/R6vTQJBB CxVQ==
X-Gm-Message-State: AOUpUlFSqDu2p+btSQmtlABc0/1nM8C84NMVEvcZpDOhAGq6tPUcucou n+40slFHBwHoYhwfJSfnbpTLYsPC2Le5wR0H4Krv6g==
X-Google-Smtp-Source: AAOMgpcz0wWOeRIMtMfLT2WSsj1KPOxAsYCn2AeayB/sZuxAee9d+gFX2Q4fvzU4gn+gtO6lB8Hc3c1xasosnuYHnvQ=
X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr11663342itg.82.1531707571396; Sun, 15 Jul 2018 19:19:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 19:18:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Ted Lemon <>
Date: Sun, 15 Jul 2018 22:18:50 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="000000000000b17b1005711475fe"
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:19:35 -0000

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.