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

Ted Lemon <> Mon, 16 July 2018 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03D6B130F35 for <>; Sun, 15 Jul 2018 20:08:21 -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 E0741Lj3-jy8 for <>; Sun, 15 Jul 2018 20:08:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EA9F130E67 for <>; Sun, 15 Jul 2018 20:08:18 -0700 (PDT)
Received: by with SMTP id w16-v6so18862579ita.0 for <>; Sun, 15 Jul 2018 20:08:18 -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=7jbj4PHSjX3o18ukFC8/TdIwW8tJtolURT4p30m8t0A=; b=DStroOqAXqVMPe+qoD5k7siDtm4uX7j9nXxUgjCvxGTF9Rr8/Pk2HerqG61arJ0m4c HcSaPRMhJrhTPCcZgpeHNa2rD9dr8Gi35UXlT0q8zm+YYqKKYgiztH4ctMCf68Ypu5jE s//yE19vTRdzqxJoQtQbdCU/P2f7idVmu/LidAuy77EIEicpy6QLuTnQpOAfqTQRzd5v fwDdLFHYbNT3u1ZXpwwXKzYpATs0wBtbpsjeC9UmjNDag8E7/dd0l/+8PgOQUIyuEvlC GYxsy3kXyjgEKrJEy9nml+G6KxgwtTOI6tM4PAxmSPaal+h+1LUePpJnzPFbLcLsPCek A5OA==
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=7jbj4PHSjX3o18ukFC8/TdIwW8tJtolURT4p30m8t0A=; b=lGYxNXbk/6pFnprum2GN6O9oYw0fCOx/N5AAIY4vOJ16n1w/HkbdQiyrnzJtn4FZaD HnDewbMnfG/9NoJa1alT5YoRtvD9Lt8P17UkmRlUKyF29VWkEFJGWcIqA8SjdWJR3QI2 GXuPVFXlXUJPGJJrqrjl/Si2tyiYpcWRqOKDOhG97DFZeklh2g83HKtcQPN9B8El+Bf/ yQYOh7fM6dq6PiZsVFh5zyssAA8SOnffArBcAOc1YAFKf+OKlqzoLZSdCQ7D1jLr4GEt BfSaUNlXvdWDkYVdEd7hzI2wQ6NaTJ8JdeYw1JMICu/8wYi8l/MnFDoqjn4bxhsplhYv Ytlw==
X-Gm-Message-State: AOUpUlGah+VC4oreXF+vUeU41bJ2i8QOZfRfXoU8UwIqEyomBdE3xSMu /G6CFwf6Sb/mPnyumDkpYHUPRe4hNz0VTiX0jdiIwQ==
X-Google-Smtp-Source: AAOMgpcIOVnWTuYsJAM6EUmddH5H/AO1zpoRP66bcWuRyiGxvh+5bIEyI9EauMkFVmeG0Y3igRX66TKxLOW7+/aLl2w=
X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr11730804itg.82.1531710497753; Sun, 15 Jul 2018 20:08:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 20:07:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Ted Lemon <>
Date: Sun, 15 Jul 2018 23:07:37 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="0000000000001e28b305711524ec"
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 03:08:21 -0000

OIC, you mean which domain should be used to discover the default
registration domain?

Is this better?

On Sun, Jul 15, 2018 at 10:44 PM, Tom Pusateri <> wrote:

> Thanks for the quick response.
> On Jul 15, 2018, at 10:18 PM, Ted Lemon <> wrote:
>>         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.  :)
> To discover the default registration domain, you need a domain in the
> query: dr._dns-sd._udp.<domain>
> domain could be .local or it could be something else. You don’t specify
> what to use here.
> 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.
> Ok. Should there be any checking on the server to make sure the TTL is
> valid from the client. The only advice is make sure the TTL is the same for
> every record in the RRset. Should the server make sure it is <= to the
> lease lifetime or any other checks instead of just blindly accepting the
> value from the client? If the TTL value is greater than the lease lifetime,
> what error should the server return for the registration?
>> 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.
> I disagree. By admitting you need an extension, you are proving my point.
> Thanks,
> Tom