Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

Toke Høiland-Jørgensen <toke@toke.dk> Thu, 12 July 2018 10:40 UTC

Return-Path: <toke@toke.dk>
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 CD3431310C5 for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 03:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 TcSojT0CgGyl for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 03:40:35 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C87130DDA for <dnssd@ietf.org>; Thu, 12 Jul 2018 03:40:34 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531392030; bh=h6mrJyneWTe9iJLSvahdcsQgYHqekvy3h5NGnwzUBTw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RvaN8IxYYwF+JNVZbQAY9F8IOXlh4JKqjdzin3ZmTAZWI2AzG4A6eo+H3qNoUWquQ Oumb0sm+/LUcHrYAsD/xpIWgpkPNJBewaElO/xpj08D++8bDKGFcMMjinfO+aAmaiM CZJk/FAanPpoLo7bozCh5rpqhZP50Lepd2x1IVi2PxoP05oQGmT0sRhyLugfD9Mnx/ HFu6TAa0ejTa5KYF7MEqUtQG3iFR6C+3hckqjNRwKx3PZsbDMOYZX9t0E6g37653Ng wqhS9vtLiEVVn0GrNteihEprXSHVJrTpBpQ9/Ordpx1f8hByU12u2OEx3/bkQJg+vP itGFwHUijf9hA==
To: Ted Lemon <mellon@fugue.com>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
In-Reply-To: <CAPt1N1=kNRiNLMEkSjMmcG+U5Bg6OACkQTAkO6t1b-rzYnza0w@mail.gmail.com>
References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <EB70166C-B64B-4509-909D-76978CA00A36@apple.com> <87lgare65v.fsf@toke.dk> <AC270951-0AA4-45D0-9F1A-83067489BF27@fugue.com> <87in5td3ar.fsf@toke.dk> <A667C059-FEBB-4159-A053-0B7AFE35F5FD@fugue.com> <87r2kbcl3h.fsf@toke.dk> <CAPt1N1=kNRiNLMEkSjMmcG+U5Bg6OACkQTAkO6t1b-rzYnza0w@mail.gmail.com>
Date: Thu, 12 Jul 2018 12:40:29 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87fu0obuua.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/WCP-j4mEUWHxgJhyf5TQ6yg313k>
Subject: Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"
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, 12 Jul 2018 10:40:38 -0000

Ted Lemon <mellon@fugue.com> writes:

> I just did a somewhat larger-than-expected update to the document to
> capture Toke's comments thus far. I also got a surprise guest review
> from a friend of mine, Tamara Kemper, who revealed a few opportunities
> to make the document clearer and better scoped. In the process of
> doing these two things I noticed that I'd fairly significantly
> misstated how SRV records work and left out some important details.
> The new document fixes all of these things (I hope). Sorry for adding
> so much text during an adoption call, but I didn't want to leave it
> for later because it would have made reading the document kind of
> unpleasant for Stuart, who I hope will review it this weekend, and if
> I hadn't done it now it would have taken at least twice as long later.
> The good news is that I'm pretty chuffed about the quality of the
> document now.

Thanks for the update! I think this version addresses my concerns from
the previous round. :)

A few other comments based on a quick read-through:

- Since registrations are always done with .local, it is up to the
  registration server to decide which domain(s) the registration ends up
  in, right? How is it supposed to do that if servicing multiple zones?
  Just based on source IP?

- The document says that clients must generate their own reverse PTR
  records. Should the server be able to do that on the clients behalf?
  It may be a matter of policy which ranges have reverse domain
  delegations...

- Related to the above, is it permitted for the registration server to
  modify the records submitted by clients before putting them into
  DNS? For example, to add PTR records, or to remove a subset of the
  records etc? The alternative to modifying would be to reject the whole
  registration if a subset is not admissible. If the server *is* allowed
  to modify things, should it communicate back to the client what it
  really did?

- You mention in the text that a network may use a different domain than
  ip6.arpa for reverse PTRs. How does that work? Won't clients always
  do reverse lookups to ip6.arpa?

-Toke