Re: [dnssd] draft-sctl-service-registration call for adoption

Tom Pusateri <> Thu, 19 July 2018 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F54713113D for <>; Thu, 19 Jul 2018 11:27:42 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PvtM02dyVFJO for <>; Thu, 19 Jul 2018 11:27:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFABD131137 for <>; Thu, 19 Jul 2018 11:27:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D1030E03; Thu, 19 Jul 2018 14:25:44 -0400 (EDT)
From: Tom Pusateri <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B10DD905-A94D-401D-B771-E05A11E13BD4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 19 Jul 2018 14:27:37 -0400
In-Reply-To: <>
Cc: Ted Lemon <>, dnssd <>
To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [dnssd] draft-sctl-service-registration call for adoption
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: Thu, 19 Jul 2018 18:27:48 -0000

> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <> wrote:
> Ted Lemon < <>> writes:
>> Tom, there are a couple of problems with what you've said. First, the
>> goal of SRP is actually to provide a general solution for registering
>> services to be discovered using DNSSD. It is not for constrained
>> devices only, although that is certainly one case where it's valuable.
>> So we can't call it a registration protocol only for constrained
>> devices.
>> Secondly, this is DNS Update. It's just that DNS Update without
>> something like this *doesn't work* as a registration protocol, and
>> we've seen that because DNS-SD over DNS hasn't taken the world by
>> storm in the years since it's been published. This specification is
>> intended to correct this problem, not to provide a second protocol
>> that can be used in a constrained set of cases.
>> It's true that FCFS doesn't work for all use cases. This specification
>> acknowledges that and talks about how to address the problem. We've
>> also had discussions about this at the mic. This protocol is however
>> the enabling technology required to solve those problems as well.
>> Those will be subsets of this, rather than this being a subset of
>> those.
>> So although I understand where you are coming from, I do not agree
>> with your analysis of the situation.
> As someone whose primary interest in this draft is naming devices across
> (logical) admin boundaries, I can only agree with Ted here. This is by
> no means just a thing for constrained devices.
> Oh, and I do also support adoption of the draft, if that hasn't been
> clear from my previous messages :)
> -Toke

While you want it to be used for this purpose, it’s not really designed for crossing administrative boundaries.

1. You need encryption which it can’t do because of the multiple packets required to do key management.
2. DNS Update does solve the administrative boundary problem at the expense of more packets back and forth to the update server. That isn’t a problem for you.
3. You don’t need the features this draft is good at.
4. This draft could do more than constrained devices but then DNS Update already does it.