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

Ted Lemon <mellon@fugue.com> Thu, 19 July 2018 19:09 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F18130E81 for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 12:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxIjFwMuSuJx for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 12:09:55 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D88E130DC6 for <dnssd@ietf.org>; Thu, 19 Jul 2018 12:09:50 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id 72-v6so11357639itw.3 for <dnssd@ietf.org>; Thu, 19 Jul 2018 12:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com>
References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <CAPt1N1mg24bD9h6+N7EsBLbo9sDpwyAsN1TnopuZ0eAcdiNw0g@mail.gmail.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 19 Jul 2018 15:09:08 -0400
Message-ID: <CAPt1N1=XTYr9VDhivAEBxn9O=3woe4r-fLt1HLG9A7rFs6nRVg@mail.gmail.com>
To: Tom Pusateri <pusateri@bangj.com>
Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056a2ff05715eecb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/l6hD1q2Vj3SWQ-iLoaoOhD7gDUU>
Subject: Re: [dnssd] draft-sctl-service-registration call for adoption
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=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 <pusateri@bangj.com> wrote:

>
>
> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Ted Lemon <mellon@fugue.com> 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
>
>
>
>