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

Ted Lemon <> Thu, 19 July 2018 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B7EA130D7A for <>; Thu, 19 Jul 2018 08:35:39 -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 FqBWALsg0eVT for <>; Thu, 19 Jul 2018 08:35:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A79A130E3C for <>; Thu, 19 Jul 2018 08:35:36 -0700 (PDT)
Received: by with SMTP id v71-v6so10488353itb.3 for <>; Thu, 19 Jul 2018 08:35:36 -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=hWx5BWnpqE4CeBPSxRiLHYNQepAYPXgHaznKVaRWahE=; b=jMtCfp/74Jl8olnpFl62ggMBD0k/CUP8euW0yDRK7IHGgEGlX+q2RsCcLsUrKSphtd 4q/wn0oQ3XcX+VHeZXNVrPlly/WiuLFPmmV12s4oZLbHO0Bv43B9BaKe8HDjPbA5Esl9 H8wCGJI32RceT+AuaZQDblEWSv46rleHrt/B9qRF32OxCpQEaDytsa1A3iKBagGPvlKe YE7IFIxLwaIejZnpADrWLXm5+lb++e9aFap60UpskGTcl8fZEJvdcYnL0chCigZwXan9 0onilvsV1N4aVdJIoenDEdmJMZAYawl2lcB15QjLfFDYzOJ+zGqU0v5nq6yVdcgh/aMC 2Owg==
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=hWx5BWnpqE4CeBPSxRiLHYNQepAYPXgHaznKVaRWahE=; b=scTwrHnAbFRU+gN1aEvZxPKJm5wScGMLK/ML3WhHjhoshgt+LjFJq0APBLimmsldhU uNMp/960G9D8M3BJt4hIv2OBkZ7wsaSoGMIRUlFNtmsUZvVqoUpWqsTDzIeusn5HSrWd 6DpJZYYzSJPYubnZe75EgbMuGRFpppS3+HiJOSEm5OJVqCAp2UWosbENDtdDoJRzuSfn FQ+xSm5KTplOxzuv69bAVpMaSxo+eeKC8koZgWH8wUdVqtcLBVPE1QJg30KP68K+hiTY MtBJYaShOMvkyGgZutusq85m8Lo9gk4h5cKXc9eTt4X4ODhuiykjeM9fmqXaEw4c1HyD xhtA==
X-Gm-Message-State: AOUpUlHWA02j0atNZBIFxwglWzRFLZRrW8oluyP0x/uTYp9/6PMzaHyS PWxQF0avtjBQtQM5N5LZNMsXRGERFUSK3POwEEGISg==
X-Google-Smtp-Source: AAOMgpezAFjrCnOIX0tRuFqQuFjgj5qa+cCZMGAdiQTcZkOQMaVX6Lrc9cUkZCqj29BkJcFR6uQdsXI1jbBcT/S+OIo=
X-Received: by 2002:a24:8a85:: with SMTP id v127-v6mr4786836itd.98.1532014535375; Thu, 19 Jul 2018 08:35:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 08:34:54 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Lemon <>
Date: Thu, 19 Jul 2018 11:34:54 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="0000000000002c18ea05715bee74"
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 15:35:40 -0000

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.

On Thu, Jul 19, 2018 at 10:53 AM, Tom Pusateri <> wrote:

> I’ll put this on the mailing list for the benefit of those not at the
> meeting today.
> The document draft-sctl-service-registration is not a general purpose
> Service Registration Protocol. It has made many compromises to allow
> registration in a single Update message for constrained devices but there
> is no encryption or authentication/authorization mechanism that can be used
> outside an administrative domain.
> Since RFC 6763 summarizes in Appendix A:
>       Service discovery requires a service registration protocol.
>       DNS already has one: DNS Dynamic Update
> DNS Dynamic Update is generic and can handle service registration from
> anywhere under any conditions. But it’s chatty and so there is a need for
> something that is more efficient for constrained devices.
> draft-sctl-service-registration does this by instructing you how to use
> DNS Dynamic Update is a particular way. It’s a profile of usage.
> Therefore, I don’t think we should call this Service Registration Protocol
> which is a generic name because it isn’t a generic solution.
> I propose “DNS Update Profile for Constrained Services”.
> Without a name change, I don’t support adoption of this draft.
> Thanks,
> Tom
> _______________________________________________
> dnssd mailing list