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

Toke Høiland-Jørgensen <> Thu, 19 July 2018 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB058130E7F for <>; Thu, 19 Jul 2018 11:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wXcf4uImFfEq for <>; Thu, 19 Jul 2018 11:35:31 -0700 (PDT)
Received: from ( [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30996130E27 for <>; Thu, 19 Jul 2018 11:35:31 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20161023; t=1532025327; bh=9JA4fRtt8sLgqV5oZvSplrk5AfJT4OI1hQd+24sefUg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mOMOkBW+HHMkIW4sv6bj1tZeipqc2pyfcrK6l0cPoCWQOOGncyMg/yCNmVt6SNWDj Qi22zpQU1iqwfVagZqT4zuCtAIvbduMkddb4xz7VqwKgQes0ErTkqlmN7TJuVN3r5k S4i617yZTiHgXMPWqxLqdV+NKZTc1hOvkT8SisQ7nK3YQhpvY7qYgEXjfxnJyq8JbD h6sWuQ9aL9MfMu7ZQ6L5p+4q4JQ17APWGTIlaVdWytpzowhEmdExJZuvf3IJ43fPpG ZoP2mVh93xLCeI08/m8p86XZFViiGVQ/0YS8gS2v6IGFpEGqzsNhTFIg2R6ILeKP2N NPT431XrB8Jtw==
To: Tom Pusateri <>
Cc: Ted Lemon <>, dnssd <>
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 19 Jul 2018 20:35:18 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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:35:34 -0000

Tom Pusateri <> writes:

>> 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.

No, I don't.

> 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.

I don't care about the number of packets going back and forth, no. What
I care about is not having to distribute keys and configuration to

> 3. You don’t need the features this draft is good at.

Such as FCFS/TOFU authentication, you mean? Where is that in DNS update?

> 4. This draft could do more than constrained devices but then DNS
> Update already does it.

See above.