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

Ted Lemon <> Thu, 19 July 2018 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F18130E81 for <>; Thu, 19 Jul 2018 12:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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] 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 DxIjFwMuSuJx for <>; Thu, 19 Jul 2018 12:09:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D88E130DC6 for <>; Thu, 19 Jul 2018 12:09:50 -0700 (PDT)
Received: by with SMTP id 72-v6so11357639itw.3 for <>; Thu, 19 Jul 2018 12:09: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=ZJ+9bHpONc90nUMlsMw/ryA2/BUkdjDJoqT6Zg+NUxU=; b=W7EvjvZypqQhBwNHo8ijaXMnkUjl1DG6z99f5I6OvZgbCsUKLbtCQRyDYoTxML7Zbj la5YCIEHr91GP8bioGCmzASmlk2bJypkVEZZ7WmyqX/6BBmImEUG8xRvktocS4xzDCRZ 3vKtdaXraVpscFKx/QyARjKe7vXPr16kiRammfd+ymPGodwrHR7SryUtSjDIjV3uaW1d IBliWE3ofL5Gl8g6ISBznw6sk2LCELOBgottdmLUs+QhqXW52eNCZIUc4xyH1V91pDd+ uu6No2yQHzZ1sQHAd2g5Xom4wYjFPjhB1n0jQjQt36X3gzuE1L9xwKyvBWGkmV8qJEqI udYw==
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=ZJ+9bHpONc90nUMlsMw/ryA2/BUkdjDJoqT6Zg+NUxU=; b=jZ3xAgQ85l4CeSAvAZvZAmtgsNpBRZbPQAgqoZyk091MLA4dpw43MrokJ+UJSsGtwu Uqrp7K06tlQ4bnTN5hbVq5zbAS/RLgdeLzlJR0WT5Kp6gAT8A0KxCLNi1FFEESmuY1vP ZSndcOz90px6egwL6SMtDToiwQDOW8FBfYcUGO5VBXdGwTRfsT4nv3ytqdNuGOzQS60T hQHEr1TcAtOWDplFSKKk6K9R+LJm2OmUPXhWQb4gGZnl/iIoM5tVaMBwYZS1xOLDZJw9 lorGhBZtfDkRww14VLGIyFqnP9nSSKeiSZIUAI3Ws9PBezAf2DCtBr6s1iQdpkuFXetZ Kzdw==
X-Gm-Message-State: AOUpUlF006jVZQAs7r83NhNk+ZvNeTaCWEDPiHxACDYjoHFUTN+rLF5v ZUsBwYDI0lIoMuSSQACtz7o6vqg0Z0cMnDoWdHVLpw==
X-Google-Smtp-Source: AAOMgpe2ePVtEw37QmPKKbGw0wJjcuyV2OhbLKui3lrdBm0/kMQTLhkwIGPM/W01wf738ay40Ydrx+EsucJUl24pVA0=
X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr6803742itb.144.1532027389510; Thu, 19 Jul 2018 12:09:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 12:09:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Ted Lemon <>
Date: Thu, 19 Jul 2018 15:09:08 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <>, dnssd <>
Content-Type: multipart/alternative; boundary="00000000000056a2ff05715eecb1"
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 19:09:58 -0000

You actually talked in your presentation on the charter about an SRP
relay.   I think that is a good approach for Toke's use case.   I don't
think there is any way to do service registration across administrative
boundaries without some kind of trust mechanism of this sort.

On Thu, Jul 19, 2018 at 2:27 PM, Tom Pusateri <> wrote:

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