From nobody Mon Jul 2 14:07:47 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9442E131317; Mon, 2 Jul 2018 14:07:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153056565655.16082.13792644710116331897@ietfa.amsl.com> Date: Mon, 02 Jul 2018 14:07:36 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-relay-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 02 Jul 2018 21:07:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Multicast DNS Discovery Relay Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-mdns-relay-01.txt Pages : 29 Date : 2018-07-02 Abstract: This document complements the specification of the Discovery Proxy for Multicast DNS-Based Service Discovery. It describes a lightweight relay mechanism, a Discovery Relay, which, when present on a link, allows remote clients, not attached to that link, to perform mDNS discovery operations on that link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-relay/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-mdns-relay-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-mdns-relay-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-relay-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 3 08:12:47 2018 Return-Path: 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 7E877130E09; Tue, 3 Jul 2018 08:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com header.b=OpFiogvy; dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com header.b=b3T30eTd 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 6Ob3rD2E7-3c; Tue, 3 Jul 2018 08:12:43 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 E86531277CC; Tue, 3 Jul 2018 08:12:42 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id p17-v6so3632778itc.2; Tue, 03 Jul 2018 08:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=40TPGXVmZCLUbL7FQlTbLbompWkHVlr6Vpc2c4HV6dk=; b=OpFiogvyqbUxAStYFYmg1yXdSqfRK4AB8cXmbPzj5mAH+iRI4/OBpEJIzyGKjj/GHy OYEC0hNTeBigXWKBSa7y2RwhBQbihBwR7JNJNrGtk/cBe+81wNfpaxgb2MMcaSUpjSbD eYKS7ltOftkHnkuEbEySAbz9YNSc2vqtBqMsKRF5NPs+OE87wIdSn6zmM6dGfrCa9cQF wi0l5mGTtqHBwTXqqJHagPTt5SsWTCJwuAhM36VxXB6O2dFi3+aO62q2d+MAHnM/EY1E XuP35A2pW/gNBueiVtrUePU9Up7mLwmd01cs6hSovKFJ0IVgRe5AG3GHaZJhCICwIz/w NUdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=40TPGXVmZCLUbL7FQlTbLbompWkHVlr6Vpc2c4HV6dk=; b=b3T30eTdgJIXiCKD1tVlX6cULXDYkKWCViqHYtLpgfX3e3wCWhe+cS5ycsrDPyphiV Elvo4BgnQ/CzENEujVISuJmrYBdRkWshXDAAkruBwS7rLF4p0uNrYUdTrCHIxwtRDNQr vepdNnaZRFM3zE+Ai29l9Q+AA0ciRY1Gal23weHZswA3RvcolI0ogfk3YJJMg4jraqto 4SupLPpJGQOcQsKjARDyGu909zTyxRKYT1nLaifollgKh4cBDPxHfa70zcwIT3sbYKe2 weLVyl4HIpuFOqQ4Zy8M5Uyl0mJGp02atwdTHWMONE8m4CaQUMOKNdMPhELpk5AluqE1 MNBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=40TPGXVmZCLUbL7FQlTbLbompWkHVlr6Vpc2c4HV6dk=; b=ne951pl7wm+e+eiswFRqvzT8sv45SWbvt7lC39ATfUTK4DchUOzyNyONLagi2TmJs8 hCroVhRSheyio5FZg2dqMpzV8dhse4l10i1c47I9M+nKLSLwbdk0jFEy0RDVFB0N3zNk ON44y5WfTvz+1ypZTgyH98M1jUEI3ISuUg+0bhZ7xeSk6bCwoK4eylUWwVca0ETrJx+U T9lPIf/D5HZvxJ18O8rQeneFOfvWw7uohQi5mxgGlWfPrWxGao0439wk5iZBYPikkbA+ 7RbS7lbDuaIGiPcWiu85mbxaiAROKhf2gooToabtEiXuWAkuD1eiwZPg6rCbJyvMRtDD lfJw== X-Gm-Message-State: APt69E2ZcjvcS/4TI8IWlJBfbKzdOsWri52eBrQxF5n4PFYMcTOanAPv QXk/gXeDDlRNP2ctn1iGQYECRnp+79QHh622x+c= X-Google-Smtp-Source: AAOMgpfSfnJU7VHeTa4z2gL8HrHDDNdfWsDfbi/ID2L0tSN83QUUe9RxR952BgiE9VB6BSHFkIQxQgglnXl1xfK0MEM= X-Received: by 2002:a24:3001:: with SMTP id q1-v6mr13450555itq.60.1530630762163; Tue, 03 Jul 2018 08:12:42 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 2002:a4f:1307:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:12:41 -0700 (PDT) In-Reply-To: <0AA55892-C183-4A58-A32E-C4D32C1E1348@apple.com> References: <0AA55892-C183-4A58-A32E-C4D32C1E1348@apple.com> From: Kerry Lynn Date: Tue, 3 Jul 2018 11:12:41 -0400 X-Google-Sender-Auth: hJL9xOtaPleUrbBzOo3vnTl_5rQ Message-ID: To: David Schinazi Cc: dnssd , dnssd-chairs Content-Type: multipart/alternative; boundary="000000000000dc7209057019be8c" Archived-At: Subject: Re: [dnssd] Call for Agenda Items: DNSSD @ IETF 102 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 15:12:45 -0000 --000000000000dc7209057019be8c Content-Type: text/plain; charset="UTF-8" I'd like a slot to discuss the CoRE Resource Directory -> DNS-SD mapping proposal https://tools.ietf.org/html/draft-ietf-core-rd-dns-sd Kerry On Thu, Jun 28, 2018 at 2:10 PM, David Schinazi wrote: > Hi everyone, > > DNSSD has been scheduled at 9:30-12:00 on Thursday Morning (July 19, > Montreal time). > If you would like to present, please send the chairs < > dnssd-chairs@ietf.org> your agenda items and expected slot duration. > The cutoff for these is Tuesday July 2. > > Thanks, > David Schinazi > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --000000000000dc7209057019be8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like a slot to discuss the CoRE Resource= Directory -> DNS-SD
mapping proposal https://tools.ietf.org/html/draft-= ietf-core-rd-dns-sd

Kerry

On Thu, Jun 28, 2018 at 2:10 PM, David S= chinazi <dschinazi@apple.com> wrote:
Hi everyone,

DNSSD has been scheduled at 9:30-12:00 = on=C2=A0Thursday Morning (July 19, Montreal time).
If you would l= ike to present, please send the chairs <dnssd-chairs@ietf.org> your agenda items = and expected slot duration.
The cutoff for these is Tuesday July = 2.

Thanks,
David Schinazi

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--000000000000dc7209057019be8c-- From nobody Tue Jul 3 09:06:32 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 029FB1310C6; Tue, 3 Jul 2018 09:00:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnssd@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362600.4893.12492563267409200313.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:26 -0700 Archived-At: Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 102 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 16:00:36 -0000 Dear Tim Chown, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (2:30 requested) Thursday, 19 July 2018, Morning Session I 0930-1200 Room Name: Duluth size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/dnssd.ics Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Tim Chown Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: v6ops saag 6man dnsop homenet dprive 6lo intarea anima core Second Priority: babel ipsecme People who must be present: Tim Chown Terry Manderson David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 12:04:50 2018 Return-Path: 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 5D620130F59 for ; Tue, 3 Jul 2018 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 MvX5QeBBISl7 for ; Tue, 3 Jul 2018 12:04:46 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65186130FAE for ; Tue, 3 Jul 2018 12:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530644643; x=2394558243; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2hJbzKnozYJlQTUJpTj29p9ZvA22Y48zTvGVmXA+n+I=; b=d9enSXLXDn68uSiFxL0KrVXttO1m8tUkC68jVxgN5/Y3igHOTXUmoEvr5OVPnVr8 rRGm5V1BA0PeaP+cPWe90xcR9deTva3PUGC3WQrOhaBww/J/bgAqVG/GaKGAONOf /z2/aEPbK3S1KwlmRbqcpMyT3oiDI8Xz17HUM9I3bjxfaPZSWGzvjvF52gx7/y/t uuNM0JLsi6/kHbn2QnfQ1YTFl/tGzrN0hnjF6Vx5vW4kLBEdR3G6irGQwnDhBjPl pYAWynpgNNCIwuEaLN6PzoTGHS7bDlEKIIepM1iVRP5SctmW8unQDKyswicRBMgb lSbTAQeabIvhPQlH4TDGeg==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 03.8F.06700.2A8CB3B5; Tue, 3 Jul 2018 12:04:03 -0700 (PDT) X-AuditID: 11ab0218-60d899e000001a2c-8a-5b3bc8a209fc Received: from crk-mmpp-sz03.euro.apple.com ( [17.66.12.165]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id D0.E9.00572.2A8CB3B5; Tue, 3 Jul 2018 20:04:02 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBB00N230YN2EA0@crk-mmpp-sz03.euro.apple.com>; Tue, 03 Jul 2018 20:04:02 +0100 (IST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <0524A205-B427-42A7-95DB-C1FC5A5EF257@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_33B38753-7106-4C0B-B586-4961350B9280" MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 03 Jul 2018 12:03:58 -0700 In-reply-to: <0AA55892-C183-4A58-A32E-C4D32C1E1348@apple.com> Cc: dnssd-chairs To: dnssd References: <0AA55892-C183-4A58-A32E-C4D32C1E1348@apple.com> X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi6GTOo7v4hHW0wdF5khZX3vUxW7xfOovR gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZvxZsZC7Yqltxr/8IUwNjv0YXIyeHhICJxK+Lv9m7 GLk4hAS2MElcftzACpPYOOcqM0RiBZPEtqYJUE4Dk8T6w+vAqoQFpCW6LtwFsjk42AS0JA6s MQIJ8wrYSEzeuZoFxGYWSJI43NHJDhE3lli/eSFUq43Ek8Z/YDaLgKrEjN1rwOo5BWwl/nX+ ZYfo1ZDYefYbmC0iICWx6/ccJhBbCKj3/tzv7BCHKkr0rznEBnKbhMAMNomu0wvYJjAKzUKy exaS3RBxbYllC18zzwI6m1lAR2LyQkaIsLzE9rdzmGFKPp4/wrSAkW0Vo3BuYmaObmaekYle YkFBTqpecn7uJkZQDKxmktjB+OW14SFGAQ5GJR7eFaXW0UKsiWXFlbmHGKU5WJTEeT/uEosW EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiQJn56asysWxs+tFaxnDspKKnyvarggM5FqdIu Sb258x/KWv7t9J5SefZhj2r6v1/HZn7kSbCR+Px3buLHV1Y3L9VvrTZ3EGT5pjDv0Kqls/iM P97bulW99aHD3pOS2cL1H1Lcn+vzTvRacIKZOU7i1Nd0fg+O4sOzBbP9q3c+NK3lXfRtsaQS S3FGoqEWc1FxIgBS5rXvYgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi6MSzVHfRCetog75vuhZX3vUxW7xfOovR gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZvxZsZC7Yqltxr/8IUwNjv0YXIyeHhICJxMY5V5m7 GLk4hARWMElsa5oA5TQwSaw/vI4VpEpYQFqi68JdIJuDg01AS+LAGiOQMK+AjcTknatZQGxm gSSJwx2d7BBxY4n1mxdCtdpIPGn8B2azCKhKzNi9BqyeU8BW4l/nX3aIXg2JnWe/gdkiAlIS u37PYQKxhYB678/9zg5xqKJE/5pDbBMY+WchWTcLyTqIuLbEsoWvmWcBXcosoCMxeSEjRFhe YvvbOcwwJR/PH2FawMi2ilG0KDUnsdJIL7W0KF8vsaAgJ1UvOT93EyM4dM15djC+Omh4iFGA g1GJh3d3jXW0EGtiWXFl7iFGCQ5mJRHebapW0UK8KYmVValF+fFFpTmpxYcYpTlYlMR5Jysx RwsJpCeWpGanphakFsFkmTg4pRoYV6xYsG0pW3fuptXrheT39OtsuKL/pvsPyx2B75cbymyf 7D3WHqmll7Fde5ftPnMVXk9pi4jVZ28Kh1/uPrZwq3XagsSdy9+uNT9ppXLlv9pdZVP1iaf+ nLITlrt5pHZnnFwdb4GEk9i2gxwLZM8kN0robrgbbCHT9Wrhj+knVj8pCJAI+prMo8RSnJFo qMVcVJwIAABDNsVZAgAA Archived-At: Subject: Re: [dnssd] Call for Agenda Items: DNSSD @ IETF 102 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 19:04:49 -0000 --Apple-Mail=_33B38753-7106-4C0B-B586-4961350B9280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks to everyone who responded. We've now posted the agenda online: https://datatracker.ietf.org/meeting/102/materials/agenda-102-dnssd-00 = Please let us know if you feel anything is missing or incorrect. Thanks, David DNSSD WG Agenda IETF 102, Montreal, Canada Thursday, July 19, 2018 9:30-12:00 Local Time (EDT) Duluth Room Introduction -- Chairs -- 5 mins Discovery Proxy -- Stuart Cheshire -- 15 mins draft-ietf-dnsop-session-signal = (DNS = Stateful Operations) Awaiting shepherd writeup and IESG decision draft-ietf-dnssd-push = (DNS Push) Currently held by working group, discuss next steps draft-ietf-dnssd-hybrid = (Discovery Proxy) Approved by IESG, waiting for DNS Stateful Operations = and DNS Push Discovery Relay -- Ted Lemon -- 15 mins draft-ietf-dnssd-mdns-relay = Working group document, discuss starting working group = last call Service Registration -- Ted Lemon -- 15 mins draft-sctl-service-registration = Individual draft, discuss adoption CoRE Resource Directory DNSSD Mapping -- Kerry Lynn -- 15 mins draft-ietf-core-rd-dns-sd = CoRE working group document, asking for input from DNSSD Privacy -- Christian Huitema -- 65 mins Discuss adoption and aim to reach consensus on way forward draft-ietf-dnssd-privacy = (Privacy = Extensions) draft-huitema-dnssd-prireq = (Privacy and = Security Requirements) draft-huitema-dnssd-privacyscaling = = (Privacy Scaling Tradeoffs) draft-ietf-dnssd-pairing = (Short = Authentication Strings) draft-ietf-dnssd-pairing-info = (Pairing = Design Issues) Rechartering -- Chairs -- 15 mins Conclusion -- Chairs -- 5 mins= --Apple-Mail=_33B38753-7106-4C0B-B586-4961350B9280 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks to everyone who responded.

We've now posted the agenda online:

Please let us know if you feel anything is missing or incorrect.

Thanks,
David


DNSSD WG Agenda

IETF 102, Montreal, Canada
Thursday, July 19, 2018
9:30-12:00 Local Time (EDT)
Duluth Room


Introduction -- Chairs -- 5 mins

Discovery Proxy -- Stuart Cheshire -- 15 mins
	draft-ietf-dnsop-session-signal (DNS Stateful Operations)
		Awaiting shepherd writeup and IESG decision
	draft-ietf-dnssd-push (DNS Push)
		Currently held by working group, discuss next steps
	draft-ietf-dnssd-hybrid (Discovery Proxy)
		Approved by IESG, waiting for DNS Stateful Operations and DNS Push

Discovery Relay -- Ted Lemon -- 15 mins
	draft-ietf-dnssd-mdns-relay
		Working group document, discuss starting working group last call

Service Registration -- Ted Lemon -- 15 mins
	draft-sctl-service-registration
		Individual draft, discuss adoption

CoRE Resource Directory DNSSD Mapping -- Kerry Lynn -- 15 mins
	draft-ietf-core-rd-dns-sd
		CoRE working group document, asking for input from DNSSD

Privacy -- Christian Huitema -- 65 mins
	Discuss adoption and aim to reach consensus on way forward
	draft-ietf-dnssd-privacy (Privacy Extensions)
	draft-huitema-dnssd-prireq (Privacy and Security Requirements)
	draft-huitema-dnssd-privacyscaling (Privacy Scaling Tradeoffs)
	draft-ietf-dnssd-pairing (Short Authentication Strings)
	draft-ietf-dnssd-pairing-info (Pairing Design Issues)

Rechartering -- Chairs -- 15 mins

Conclusion -- Chairs -- 5 mins
--Apple-Mail=_33B38753-7106-4C0B-B586-4961350B9280-- From nobody Tue Jul 3 12:21:35 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B98130DD2; Tue, 3 Jul 2018 12:21:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 12:21:33 -0700 Archived-At: Subject: [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.26 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: Tue, 03 Jul 2018 19:21:34 -0000 The DNSSD WG has placed draft-sctl-service-registration in state Call For Adoption By WG Issued (entered by David Schinazi) The document is available at https://datatracker.ietf.org/doc/draft-sctl-service-registration/ From nobody Tue Jul 3 12:22:45 2018 Return-Path: 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 C69C3130DC0 for ; Tue, 3 Jul 2018 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 aJV-rGuSn_jZ for ; Tue, 3 Jul 2018 12:22:41 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E513C130DD2 for ; Tue, 3 Jul 2018 12:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530645760; x=2394559360; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qQchdMsbF3pL5pgPQU5w8mLEHLAnKgc/LzQoSBx5Wy0=; b=Oyulq0ZYdlvv7bPl4dWDhJ04MOSPAuESAbWDq0hWAP2nTpaO4r6H5R8GOffBkvRu v1Vax86Mj0oYNCoLQfoilQo+ysWr16YwRirx2iqANOz5LgArIxiBoRFrZrIJe/Vb 7mpRmyTT1BW58/KBT42h8fbzVXeuqHj805vjAY0/uv15zpWTSveyLfCFvXyrT5Cu 5eQOyZDIWO/9JjEslshOrIgVo462EsEG8JBwHECiQGdkE/49ADW7yleUA1PGN28X COi3VirhVHIsyHhJhiboNeo0l3VSSINDIWAB9WIOuFUWXzKt4HSDDNrsotpM+mJS r2N0bZKoG3IK6k9wT4hoxA==; X-AuditID: 11ab0218-0e9ff70000001a2c-d2-5b3bccff359f Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id D1.70.06700.00DCB3B5; Tue, 3 Jul 2018 12:22:40 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rrlMheAXqVr4m7RJDt0pEQ)" Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBB0033A1TR0FH0@mr2-mtap-s03.rno.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:22:39 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001QVJY00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:22:39 -0700 (PDT) X-Va-CD: 0 X-Va-ID: 198f7c46-a3ae-4af0-a3ad-a242ee59f615 X-V-A: X-V-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-V-E-CD: 548cfe2c2448e516c0b0afd7dd315961 X-V-R-CD: fa3cb0ae0157073c569194c260c61108 X-V-CD: 0 X-V-ID: 073d78de-9306-4228-9e6a-074981c33600 Received: from process_milters-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001OO6N00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:22:38 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-03_08:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp22.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBB00LNM1TPH380@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:22:38 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Date: Tue, 03 Jul 2018 12:22:36 -0700 References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> To: dnssd In-reply-to: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> Message-id: X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUiuPlRuy7DWetog6VrBS3eL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFOTdjIWHBGp+Pqug7GBcYpQFyMnh4SAicSRVzOZuxi5OIQE DjJJTOqdwg6S4BUQlPgx+R4LiM0sECax7Ws/I0TRISaJJysfM0E4c5kkFm9+zQYxiktiwdbT rBC2rsTC8+cZIWw2ifUnljBB2FoS+07dAprKAWbvbOeGCb/bfQWqnFPi/JeJ7BC2jsSbUxvB 4kICc5gkpvyrgYhnS2zZeZEFwg6QmLd5PtQHnUwSP2dOZwZJCAtIS3RduMsKsosNaMGBNUYQ 4QKJW/9ug53JIqAq0dq2EKxESMBHonOLPEhYREBKYtfvOWAXcwr4SqzrOc8GCRMbiS+dC6HW Kkr0rznENoFRehZScM1CCi4IW0vi+6NWoDgHkC0vcfC8LERYU+LZvU/sELa2xJN3F1gXMLKt YhTOTczM0c3MMzLRSywoyEnVS87P3cQIiubVTBI7GL+8NjzEKMDBqMTDu6LUOlqINbGsuDL3 EKM0B4uSOO/HXWLRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgT2nwT/13Z9M+aa0K06878 hZpf82Me2vWVSk56cvLLm5uXlVQPHLylN135dfOMJTtN31xYrKNhq66wNvYKKxcbh4BTAG/D wT/lz4+crXvoccpym4lPcL+2pOmdubJJPHL75k/dbRd9+V7N134jT6t1Jb7+58tPPXO0/5Mo vsr3ilif/LVZzjuVWIozEg21mIuKEwGnsLIuxwIAAA== Archived-At: 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.26 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: Tue, 03 Jul 2018 19:22:44 -0000 --Boundary_(ID_rrlMheAXqVr4m7RJDt0pEQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, This email starts a three-week adoption call for draft-sctl-service-registration . The call will run until the week after IETF 102. Please review this draft between now and Montreal, we will also discuss it in person in Montreal. Thanks, David > On Jul 3, 2018, at 12:21, IETF Secretariat wrote: > > > The DNSSD WG has placed draft-sctl-service-registration in state > Call For Adoption By WG Issued (entered by David Schinazi) > > The document is available at > https://datatracker.ietf.org/doc/draft-sctl-service-registration/ > --Boundary_(ID_rrlMheAXqVr4m7RJDt0pEQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = everyone,

This email = starts a three-week adoption call for draft-sctl-service-registration .
The call will run until the week after IETF 102.
Please review this draft between now and Montreal, we will = also discuss it in person in Montreal.

Thanks,
David


On Jul = 3, 2018, at 12:21, IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:


The DNSSD WG has placed draft-sctl-service-registration in = state
Call For Adoption By WG Issued (entered by David = Schinazi)

The document is available at
https://datatracker.ietf.org/doc/draft-sctl-service-registratio= n/


= --Boundary_(ID_rrlMheAXqVr4m7RJDt0pEQ)-- From nobody Tue Jul 3 12:23:38 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE27130DD2; Tue, 3 Jul 2018 12:23:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153064581424.5078.131915466136816280.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 12:23:34 -0700 Archived-At: Subject: [dnssd] The DNSSD WG has placed draft-huitema-dnssd-privacyscaling in state "Call For Adoption By WG Issued" X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 19:23:35 -0000 The DNSSD WG has placed draft-huitema-dnssd-privacyscaling in state Call For Adoption By WG Issued (entered by David Schinazi) The document is available at https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacyscaling/ From nobody Tue Jul 3 12:23:49 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 097F2130ECA; Tue, 3 Jul 2018 12:23:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153064582703.5095.10292096887233419308.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 12:23:47 -0700 Archived-At: Subject: [dnssd] The DNSSD WG has placed draft-huitema-dnssd-prireq in state "Call For Adoption By WG Issued" X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 19:23:48 -0000 The DNSSD WG has placed draft-huitema-dnssd-prireq in state Call For Adoption By WG Issued (entered by David Schinazi) The document is available at https://datatracker.ietf.org/doc/draft-huitema-dnssd-prireq/ From nobody Tue Jul 3 12:24:09 2018 Return-Path: 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 10D13130DE9 for ; Tue, 3 Jul 2018 12:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 5VErZcoNfdq5 for ; Tue, 3 Jul 2018 12:24:04 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52554130DC0 for ; Tue, 3 Jul 2018 12:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530645843; x=2394559443; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NSECjw1LiqhmXAVl2fLLApKCbO3zpAxQdNxDZKWlydI=; b=UBKLOwPscYJJ3s23HDdUmnrgBZjWOV41gNBeHxSIFr7LjoAqPxzgwMxc+oBxGgCs AxWhvD3ThWi4eq4A3XWqH1aimmnK5FI1i8C2D2c8RKF5RbvBXWnPDeSABHz8yoxV IH615b2LF9FBek+yyarHZritJxr6jX1bjEq9pgHEQkipj7OWZuLuI+CkXduurEWk sJ6bqZ/vfbXbgurCcoCUeieypgHi9Jamw9sDxFjcavBDHvFHdlVzjOivByBEqy0v 32BNpu+r750K82fc4FtlgW+IT5tAIdTOz3smEFMHo/viPurbukZynZC8KfeGBxm6 NIHwl/X83KNI7PnjPuqGmQ==; X-AuditID: 11ab0217-d27ff70000003e90-32-5b3bcd521ff1 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 47.40.16016.35DCB3B5; Tue, 3 Jul 2018 12:24:03 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YYfYuy49VhUE3eTNB+P/Bw)" Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBB008311W2DW10@mr2-mtap-s03.rno.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:24:02 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001QVJY00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:24:02 -0700 (PDT) X-V-A: X-V-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-V-E-CD: 7563ffb0b3ffc69942826d6b68e9588d X-V-R-CD: e9271a6020cea71ad8375bda47633693 X-V-CD: 0 X-V-ID: 8f8d0025-061a-43e4-b206-755eff51b692 Received: from process_milters-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001OO6N00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:23:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-03_08:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp23.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBB00LOX1VVH380@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:23:57 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Tue, 03 Jul 2018 12:23:55 -0700 To: dnssd X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42IR3PyoXTf4rHW0wb09chbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxquVU1gKugQqZq2awtTAuISvi5GTQ0LAROJRz0mWLkYuDiGB g0wSSw5eYwJJ8AoISvyYfI8FxGYWCJP4cXweE0TRISaJfYfOsYMkhATmMkn8bbGEmMQmsf7E EiYIW0ti36lbLDD2qqcTmWHsw4/vQtVwSpz/MpEdwtaRWHD/GCvEzDlAV9wvhohnS2zZeRFq ToDEmoU/GSGO6GSSuLv5DliDsIC0RNeFu0A2Bwcb0IIDa4wgwvoSLVt3sEI8YyMxZd4UsL0s AqoS668tBNsrIiAlsev3HKh7FCX61xxim8AoPgvJ/7OQ/A9ha0l8f9QKFOcAsuUlDp6XhQhr Sjy794kdwtaWePLuAusCRrZVjMK5iZk5upl5RsZ6iQUFOal6yfm5mxhB8baaSXwH4+fXhocY BTgYlXh4V5RaRwuxJpYVV+YeYpTmYFES5/2wSyxaSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6PD7EmfPv5SeXOsed2hmV0H4gXz/1znCcpM7lvOoPqwZGPIvoqVK0zZhNe6C96+0qS24MkT oXdr86pW18Re+vvc8km35pmptYayxkYiXndy5nw4JM9xwZvzzLFPZ4MMYlVzEsLP/YjyuT9n stL8nGObj7BuMzUNMkl/99igpnv7zXxx290fP0gosRRnJBpqMRcVJwIAa+HqiZgCAAA= Archived-At: Subject: [dnssd] Adoption call for DNSSD Privacy drafts X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 19:24:08 -0000 --Boundary_(ID_YYfYuy49VhUE3eTNB+P/Bw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, This email starts three-week adoption calls for both draft-huitema-dnssd-prireq and draft-huitema-dnssd-privacyscaling . The call will run until the week after IETF 102. Please review these drafts between now and Montreal, we will also discuss them in person in Montreal. Our privacy goal for Montreal is to reach consensus on the privacy, security, and scaling requirements for a DNSSD privacy solution. Thanks, David --Boundary_(ID_YYfYuy49VhUE3eTNB+P/Bw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = everyone,

This email = starts three-week adoption calls for both draft-huitema-dnssd-prireq and draft-huitema-dnssd-privacyscaling .
The call will run until the week after IETF 102.
Please review these drafts between now and Montreal, we will = also discuss them in person in Montreal.

Our privacy goal for Montreal is to = reach consensus on the privacy, security, and scaling requirements for a = DNSSD privacy solution.

Thanks,
David
= --Boundary_(ID_YYfYuy49VhUE3eTNB+P/Bw)-- From nobody Tue Jul 3 12:25:44 2018 Return-Path: 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 BFBFB130DD2 for ; Tue, 3 Jul 2018 12:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 JgPcnkz3FRrv for ; Tue, 3 Jul 2018 12:25:41 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828C3130DC0 for ; Tue, 3 Jul 2018 12:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530645940; x=2394559540; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9JVFBskL22fILsp/FyDpFObfofuaAUO0kjKbreXrBPU=; b=pb+sAqG3VOP912fF6nE4koZP/2eSNGy3HREIroJyYk9yb/Qm6b7vuM7PUwhP7JSg WkA6tBJlEXpfZCJBWFoo1s1+fEMg3egKuM+zSSI9pIlBcIPR/8Q1iu/YDHeXito4 z27k5xs++Jd5VdBOK60qTALqYIT2vI8Z5pFdsfuFvTbfVZRzxJn4gIksL/u4goDY fdLMPIuCBqLZHK88kUHt0qWe+SyAssgYkrEx8XlQUFQaigyPxtYB1GNUqAiLyUVh Mkd9i/J0QlFBjqUQric4kIWuJfusMUGH9nAeYvumc3vHsiHvwcymOE4YzMoziRLQ RZaXl1NIzPTG4XxxEeo/HA==; X-AuditID: 11973e15-bc7ff70000007130-a8-5b3bcdb4ee3a Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 15.2B.28976.4BDCB3B5; Tue, 3 Jul 2018 12:25:40 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lsvp5LmTf5cpjUBkGcET8A)" Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBB006L31YRMMD0@mr2-mtap-s01.rno.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:25:40 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001QVJY00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:25:39 -0700 (PDT) X-Va-CD: 0 X-Va-ID: f3d0135a-f6dd-418f-8a0a-7152942891bc X-V-A: X-V-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-V-E-CD: f784ec925e302e7ce40fd32f710a4881 X-V-R-CD: 31e0d15f45640b0689d1686451de1673 X-V-CD: 0 X-V-ID: 9188381f-1e38-4d20-b5ec-61ac9eff9cc8 Received: from process_milters-daemon.ma1-mmpp-sz07.apple.com by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBB00M001OO6N00@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:25:39 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-03_08:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp21.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBB00LQL1YQH380@ma1-mmpp-sz07.apple.com> for dnssd@ietf.org; Tue, 03 Jul 2018 12:25:39 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Tue, 03 Jul 2018 12:25:38 -0700 To: dnssd X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUiuPlRq+6Ws9bRBi/my1u8XzqL0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGUd+rWcteMlVceF/ZQPjDc4uRk4OCQETidbLN1hBbCGBA0wS N9tiQWxeAUGJH5PvsYDYzAJhEk8/72bvYuQCqjnEJHFiwUEmCGcuk8SUCf/YISZxSSzYepoV wtaVeLb/BzOEzSax/sQSJghbS2LfqVssMPaz499YYew7rx4xQticEue/TASayQFk60g0PMmD 2DWHSeLW5G6omdkSW3ZehJoTIPHo0VE2iKJOJokH69aADRUWkJbounCXFWQQG9CCA2uMIMIO EjOPP2GF+NJG4sOdV2B7WQRUJb492gtmiwhISez6PQfqZkWJ/jWH2CYwSs5CCphZSAEDYWtJ fH/UChTnALLlJQ6el4UIa0o8u/eJHUl4ASPbKkah3MTMHN3MPDO9xIKCnFS95PzcTYygyJxu J7qD8cwqq0OMAhyMSjy8K0qto4VYE8uKK3MPMUpzsCiJ85ommUYLCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYGTcbpPTNO+oirrixwdp3lONzF7k++65eGjO6lUFKZI8Bw8ob33x9J6S5CxR 4Y1e+5urhG8eyPj2k//8XA/tTfZ+ZvnL8ktc1nidF8wJfZq3lOfSnWVs4v6vXohsnlmZePOz o3Wpfcr1FLn1fAG3U5e9zXNa8mHhmmMKblxMtw+L+EuL+x5bv0aJpTgj0VCLuag4EQDYHzr9 rQIAAA== Archived-At: Subject: [dnssd] Working group last call for draft-ietf-dnssd-mdns-relay X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Tue, 03 Jul 2018 19:25:43 -0000 --Boundary_(ID_lsvp5LmTf5cpjUBkGcET8A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, This email starts a three-week working group last call for draft-ietf-dnssd-mdns-relay . The call will run until the week after IETF 102. Please review this draft between now and Montreal, we will also discuss it in person in Montreal. Thanks, David --Boundary_(ID_lsvp5LmTf5cpjUBkGcET8A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone,

This email starts a three-week working group last call for draft-ietf-dnssd-mdns-relay .
The call will run until the week after IETF 102.
Please review this draft between now and Montreal, we will also discuss it in person in Montreal.

Thanks,
David
--Boundary_(ID_lsvp5LmTf5cpjUBkGcET8A)-- From nobody Wed Jul 4 01:50:40 2018 Return-Path: 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 C8D2C130DC1 for ; Wed, 4 Jul 2018 01:50: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 RtaV_v85cZ3Y for ; Wed, 4 Jul 2018 01:50:34 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A1012426A for ; Wed, 4 Jul 2018 01:50:34 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530694228; bh=6XbUF3GIu2k5cEPNnYat5gyirL8g9Jf/IZGaCOKCSLY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=bC8gZGHIas+8qC9vwREveNF80QiR/MQNVKjxbnUN0qFfZTwZcHufyEOZwiFMoNZEF b7gBU2ULs/khjLxkgKaalEw1KXNsjAeyEs3ejztVfW+Vr7nItwjCiYd3ANTIYg4Fn5 CFwoToaPYUh+udTL+oI3IGsxmT0qftisi6aj/BljvpEzxS6NEo487eBQ6Bfdh6XNQa t2egLw0BWE202U/bHL3xxN1ISNqQCro25INT8y4oQqPHAoSohGQE1Vb4y6wcGT1gDB oa22dC7GsrOoqq/BrNOnHXReDpbg7OaODRDwd/iQLDobLNrZ0NSjXftK/+5L7oEzoi Y2J22ApueVslw== To: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2018 10:50:20 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgare65v.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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.26 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: Wed, 04 Jul 2018 08:50:38 -0000 David Schinazi writes: > Hi everyone, > > This email starts a three-week adoption call for > draft-sctl-service-registration > . I provided some comments on the -00 of this draft back in October[0]. The -01 version addresses one of them (related to how to specify the TTL), but the others are still relevant, I think. I don't believe these comments should block adoption, but I figured this would be a good time to repeat them, since I received exactly zero (0) responses on my previous email... :) Relevant parts of the previous comments below: - It is not clear how to find the server to register with: Section 2 refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to RFC6763 Section 11 for information on how to discover the zones to attempt registration in. So from my best reading of this, the client should discover the relevant zones, then just send its signed updates to any authoritative server for those zones. However, this prevents implementing the registration logic as a proxy (as I'm currently doing). So I feel like there should be a SRV lookup in there somewhere? I seem to recall Stuart telling me that this is indeed specified somewhere, but my google fu is failing me right now, and in any case it's not clear from the draft how this process is supposed to work. - Address-based ACLs: Obviously, in most cases a client should only be able to perform registration if it is actually on the right network. Firewalling off the ports from outside the relevant networks is a way to ensure this, but it is somewhat of a crude tool. For one, it prevents a single registration server / proxy from serving multiple networks[1]. For another, it prevents a use case where a client is only allowed *initial* registration (when the key is first cached) from inside the network, but is allowed to subsequently update the same record from anywhere. This is useful to, for instance, have my laptop maintain my-laptop.myhome.example.org even when visiting another network. So another way to ensure this source verification is needed, I think. The way I implemented it is to have the registration server only speak TCP; that way, source address spoofing is not possible (as that would make the handshake fail), and the server can simply implement a straight-forward ACL policy. - It is not quite clear to me whether the sleep proxy described in section 4 is an optional feature or if its meant to be mandatory. Stuart explained its usefulness for devices that power off when not in use, requiring this function will mean that registration servers will need to be on the local link, which is somewhat limiting. Also, the implementation complexity goes way up (I certainly don't plan to implement this feature :)). So I think having a way for the server to signal "no, I can't perform sleep proxying" to the client would be good to allow things to fail in a graceful way. -Toke [0] https://mailarchive.ietf.org/arch/msg/dnssd/n1H-OGDx8BioVqjTuDTz6jmUmoo [1] I'll add that since the -01 draft now says that the update should always be for .local, how is a registration server supposed to know which domain a client wants to register in? By source address only? From nobody Wed Jul 4 06:45:48 2018 Return-Path: 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 CFF81130F70 for ; Wed, 4 Jul 2018 06:45:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 jxhz26K8Mt4V for ; Wed, 4 Jul 2018 06:45:44 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 8C916130F88 for ; Wed, 4 Jul 2018 06:45:43 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id u62-v6so2866153qkf.9 for ; Wed, 04 Jul 2018 06:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHORzgOUJLRgKeTXYL12pbtDqt6+sEY1h9shWcPpE9M=; b=bf3umpM6bjK4GWe7JosJ4hd84EyXHS+eny7w22XSeyLD04rvlwkLf086NmatN/Sbnl Xaeo66I2bhvNczfphsHCq8ILCfgU7fPuH6ckTNQxjw5huWbIVTdVCH6Vs7aW2VIBak25 Bt204zkliNg2rzY0mHtYOWTxaj6gn6XQG9kyIrYy8Or0BsXGHYset1J68N/0Vzv3KvX8 xmmGxXbCUrTPPO5u4toRqIlmJ7EJBcu9WGXMP/dWbkqB2VJv7oZxYB7oxE7j+4aeyupc iNewJCiN4EpkfgHMqD+2IBuBIvbRDhlffow62CER5nRC7R3UrGRvPvSALygroGBtSOqe +avA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHORzgOUJLRgKeTXYL12pbtDqt6+sEY1h9shWcPpE9M=; b=N8goKksh1VyOKEg3/Auzn61V3c8p287TXumQJ7VBlpx+rVbw7QPdx/BRht+hNkA8eR M0U4QnzZcZ4dxs4pjbgXwG/2JA33CyXz9vbMaiTUoxb1OKXfsHcmsT/K8cvm84eAqWwA F+MYjhxE3peXGzVVOo7JFNCN4XXjSkpMYawi8fF6I86hPKSQv4qfM82ytU94s1dAn1Bc hSm/XYdR6GBomgUtQVNpQBumVVBiAyMrKCyvr2oXX8RpSNMFLLTP/Q1GwJTW6hj09Cpe xg0UZX/f7meY89a3yml8JVZ2RXxAaK6F2vDUQTnWk7t+j1yqURDjO3omez2bFrdhZjnr pCbA== X-Gm-Message-State: APt69E1TL5xuzl8y/+JKmLJCjEcBQ82ZGDvNmGDZE4GCJtgXWQKHu+Nn Bi5o/4DOlX0eq/wUYxzWtOGGh9Mb7rA= X-Google-Smtp-Source: AAOMgpeiz/ZOqzvg2GmvnvZypjeinvreJGEAAsgX9F/D63GnV5FASl74m6Rg0S2TmmpGPz1I5eCj/g== X-Received: by 2002:a37:65d8:: with SMTP id z207-v6mr1551008qkb.81.1530711942484; Wed, 04 Jul 2018 06:45:42 -0700 (PDT) Received: from [10.0.100.12] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id g18-v6sm2717710qtg.59.2018.07.04.06.45.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 06:45:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.13.1\)) From: Ted Lemon In-Reply-To: <87lgare65v.fsf@toke.dk> Date: Wed, 4 Jul 2018 09:45:40 -0400 Cc: David Schinazi , dnssd Content-Transfer-Encoding: quoted-printable Message-Id: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.100.13.1) Archived-At: 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.26 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: Wed, 04 Jul 2018 13:45:47 -0000 On Jul 4, 2018, at 4:50 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > David Schinazi writes: > - It is not clear how to find the server to register with: Section 2 > refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to > RFC6763 Section 11 for information on how to discover the zones to > attempt registration in. So from my best reading of this, the client > should discover the relevant zones, then just send its signed updates > to any authoritative server for those zones. However, this prevents > implementing the registration logic as a proxy (as I'm currently > doing). So I feel like there should be a SRV lookup in there > somewhere? I seem to recall Stuart telling me that this is indeed > specified somewhere, but my google fu is failing me right now, and in > any case it's not clear from the draft how this process is supposed = to > work. I thought it was specified somewhere too, but it doesn't seem to be = explicitly stated in RFC 6763. In general, RFC 2136 says that any = server authoritative for the zone can be sent a DNS update for that = zone, and is directed to preferentially send updates to the master if it = is reachable. That said, Apple's implementation looks for a _dns-update._udp. = SRV record, and it might make sense to specify that explicitly. Also, = this has been specified in such a way that the client need do minimal = work before firing off the update. Stuart and I have talked about = using anycast to make this a single-transaction service in the default = case, which would be particularly nice for low-power devices. I didn't = have time to spec that out in this version, but it's definitely an = intended feature. > - Address-based ACLs: Obviously, in most cases a client should only be > able to perform registration if it is actually on the right network. > Firewalling off the ports from outside the relevant networks is a way > to ensure this, but it is somewhat of a crude tool. For one, it > prevents a single registration server / proxy from serving multiple > networks[1]. For another, it prevents a use case where a client is = only > allowed *initial* registration (when the key is first cached) from > inside the network, but is allowed to subsequently update the same > record from anywhere. This is useful to, for instance, have my laptop > maintain my-laptop.myhome.example.org even when visiting another > network. That's a good point=E2=80=94I hadn't thought about enabling the off-site = update. There are security implications of that, of course: it could = be a foothold for an informed attacker. I'm not convinced that it = should be permitted by default, and indeed in the homenet scenario, for = example, I would say that it should not be permitted by default. There = may be scenarios where it makes sense. As for the address-based ACL, that's in fact what I'm using in the = prototype. Another way to do it would be to have an anycast listener = in, for example, each homenet router, which only accepts updates from = the local wire. This listener would add its signature to the message = and forward it in an encapsulation. If we allow for a two-packet = exchange for service registration, which I think is desirable, this may = be worth specifying. In an LLN I don't think it would be hard to = do=E2=80=94it could be done at the edge of the mesh. > So another way to ensure this source verification is needed, I think. > The way I implemented it is to have the registration server only = speak > TCP; that way, source address spoofing is not possible (as that would > make the handshake fail), and the server can simply implement a > straight-forward ACL policy. This could also work, or we could use DNS cookies, but it breaks the LLN = use case. > - It is not quite clear to me whether the sleep proxy described in > section 4 is an optional feature or if its meant to be mandatory. > Stuart explained its usefulness for devices that power off when not = in > use, requiring this function will mean that registration servers will > need to be on the local link, which is somewhat limiting. Also, the > implementation complexity goes way up (I certainly don't plan to > implement this feature :)). So I think having a way for the server to > signal "no, I can't perform sleep proxying" to the client would be > good to allow things to fail in a graceful way. Sleep proxy is advertised as a service, so devices that don't implement = it can not advertise it. However, this breaks the LLN single-exchange = use case, so I think there's an argument that it should be required on = LLNs. That said, this is existing technology, which is widely = deployed, and often deployed in very tiny devices. I don't think it's = hard to implement, and I am a little surprised that you think it is. = Is it really that it's hard to implement, or is it that you don't think = it's important, don't know how to implement it, and therefore would = prefer not to? That's a perfectly valid position to take, but it's not = what you said. > [1] I'll add that since the -01 draft now says that the update should > always be for .local, how is a registration server supposed to know > which domain a client wants to register in? By source address only? I think that in a network where there is more than one domain in which a = registration could occur, something like that would indeed be required. = My base assumption in writing this text (which Stuart hasn't seen yet, = because he's on vacation) is that in most cases where this will be used, = either there will be only one registration domain, or else the link to = which the service is attached will be sufficient to decide what domain = to use. From nobody Thu Jul 5 10:02:28 2018 Return-Path: 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 CF82F130F66 for ; Thu, 5 Jul 2018 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: 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 4sW6HhwtnkJw for ; Thu, 5 Jul 2018 10:02:12 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4533130F52 for ; Thu, 5 Jul 2018 10:02:11 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530810126; bh=44phiMOOg3CD4HyOt9Amjas2VQKEp+tE0WwM0TNXVXc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PA5c38S0cHk7td5gtDE48kKpCktGr1IolHaOr4GKK4WL0RovkW31MSSEB9FII6g+J PhmyZVKj1+mkGSUHwL5dbEr4L/7HKQa/u1vqICvoaj9wVWM9nNgIohGwLdIyx2ZgrY AnBhaMXsUlXZ+zhwKjdaMf6wpID41O0s+9nk54qB9AZaajxFBbjWxIWbFMS60eyFMx ikKHQNJvO7x27hrHbMgkwB64i01CtQpaDupko/Ykco6CfWy6QTYUJ+SdIeulVVSEIN eTRUcKWk9FmOTehk7LLax3ln30/dPFQXNCl5JI77jiTZxCuqhJG76KXbiOIk1dcd7u dgF04SV6yCKxQ== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> Date: Thu, 05 Jul 2018 19:02:04 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in5td3ar.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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.26 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, 05 Jul 2018 17:02:27 -0000 Ted Lemon writes: > That said, Apple's implementation looks for a > _dns-update._udp. SRV record, and it might make sense to > specify that explicitly. Yeah, I think Stuart explained this to me at some point. But I'm not sure if "ask Stuart" is sufficiently discoverable, so mentioning it in the document might be a good idea ;) >> - Address-based ACLs: Obviously, in most cases a client should only be >> able to perform registration if it is actually on the right network. >> Firewalling off the ports from outside the relevant networks is a way >> to ensure this, but it is somewhat of a crude tool. For one, it >> prevents a single registration server / proxy from serving multiple >> networks[1]. For another, it prevents a use case where a client is only >> allowed *initial* registration (when the key is first cached) from >> inside the network, but is allowed to subsequently update the same >> record from anywhere. This is useful to, for instance, have my laptop >> maintain my-laptop.myhome.example.org even when visiting another >> network. > > That's a good point=E2=80=94I hadn't thought about enabling the off-site > update. There are security implications of that, of course: it could > be a foothold for an informed attacker. I'm not convinced that it > should be permitted by default, and indeed in the homenet scenario, > for example, I would say that it should not be permitted by default. > There may be scenarios where it makes sense. Sure, by all means hide it behind a big "I know what I'm doing" button, or something. I just don't want the standard to rule out the possibility entirely. >> So another way to ensure this source verification is needed, I think. >> The way I implemented it is to have the registration server only speak >> TCP; that way, source address spoofing is not possible (as that would >> make the handshake fail), and the server can simply implement a >> straight-forward ACL policy. > > This could also work, or we could use DNS cookies, but it breaks the > LLN use case. Wouldn't it be possible to specify both? >> - It is not quite clear to me whether the sleep proxy described in >> section 4 is an optional feature or if its meant to be mandatory. >> Stuart explained its usefulness for devices that power off when not in >> use, requiring this function will mean that registration servers will >> need to be on the local link, which is somewhat limiting. Also, the >> implementation complexity goes way up (I certainly don't plan to >> implement this feature :)). So I think having a way for the server to >> signal "no, I can't perform sleep proxying" to the client would be >> good to allow things to fail in a graceful way. > > Sleep proxy is advertised as a service, so devices that don't > implement it can not advertise it. Ah, great. As long as its in spec to not advertise that service, that's good enough for me. > However, this breaks the LLN single-exchange use case, so I think > there's an argument that it should be required on LLNs. Hmm, I'm not sure I quite understand what you mean by single-exchange use case, then? > That said, this is existing technology, which is widely deployed, and > often deployed in very tiny devices. I don't think it's hard to > implement, and I am a little surprised that you think it is. I said "harder", not "hard" ;) What I mean is that to do sleep proxying (as I read the spec) requires raw sockets, or some other way to answer neighbour requests on the sleeping device's behalf. Which generally tends to be a privileged operation, and raises the complexity from "just answer DNS requests". And of course it requires link-local presence, which means it either requires automation (such as in homenet), or lots of manual configuration. > Is it really that it's hard to implement, or is it that you don't > think it's important, don't know how to implement it, and therefore > would prefer not to? That's a perfectly valid position to take, but > it's not what you said. I think it's not important enough to put in the effort to implement it, basically. Note that this is for my use case; I can totally agree that requiring it for homenet makes sense; but service registration can be useful in other contexts as well... -Toke From nobody Sun Jul 8 20:47:01 2018 Return-Path: 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 3B209130DC6 for ; Sun, 8 Jul 2018 20:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SLz0TOk4tnwt for ; Sun, 8 Jul 2018 20:46:57 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0019130E0E for ; Sun, 8 Jul 2018 20:46:57 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 8 Jul 2018 20:46:54 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Sun, 8 Jul 2018 20:46:54 -0700 From: Terry Manderson To: "dnssd@ietf.org" Thread-Topic: DNSSD Co-Chair movements Thread-Index: AQHUFzd63QRFX6z+fUm58LHCngYBlg== Date: Mon, 9 Jul 2018 03:46:53 +0000 Message-ID: <49767CDD-E609-4EF5-A600-7CED1D4BE82C@icann.org> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <1E1C1679B638F74F9CF3A5E869754F20@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dnssd] DNSSD Co-Chair movements X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 09 Jul 2018 03:47:00 -0000 RGVhciBXRywNCg0KUmVjZW50bHkgVGltIENob3duLCB5b3VyIGxvbmcgc3RhbmRpbmcgRE5TU0Qg Y2hhaXIsIHNpZ25hbGxlZCBoaXMgaW50ZW50aW9uIHRvIHN0ZXAgZG93biBmcm9tIHRoZSBETlNT RCBjby1jaGFpciBwb3NpdGlvbi4NCg0KQmVmb3JlIEkgZ28gbXVjaCBmdXJ0aGVyLCBJIHdvdWxk IGxpa2UgdG8gZXhwcmVzcyBteSBzaW5jZXJlIHRoYW5rcyB0byBUaW0uIEhpcyB0aW1lIGFzIGNv LWNoYWlyIGNlcnRhaW5seSBwcmVkYXRlcyBtZSBhcyBBRCBhbmQgSSBoYXZlIG5vdGhpbmcgZXhj ZXB0IGdsb3dpbmcgd29yZHMgb2YgcHJhaXNlIGZvciB0aGUgam9iIGhlIGhhcyBkb25lLiBIZSBp cyBjZXJ0YWlubHkgbGVhdmluZyBzb21lIHZlcnkgYmlnIHNob2VzIHRvIGZpbGwgYW5kIGhhcyBo ZWxwZWQgbW9kZWwgYSB2ZXJ5IHdlbGwgcnVuIGFuZCBjb2xsZWdpYXRlIFdHLiBJIHdvdWxkIGhv cGUgeW91IGFsbCByZWFjaCBvdXQgdG8gVGltIGFuZCB0aGFuayBoaW0gZm9yIHRoZSAob2Z0ZW4g dGhhbmtsZXNzKSB5ZWFycyBvZiBlZmZvcnQgZ2l2ZW4gdG8gRE5TIFNlcnZpY2UgRGlzY292ZXJ5 LiBTYWRseSwgSSBkb27igJl0IGJlbGlldmUgVGltIHdpbGwgYmUgam9pbmluZyB1cyBpbiBNb250 cmVhbCBzbyBvcHRpb25zIHRvIHNoYXJlIGEgYnJldyB3aXRoIFRpbSBtaWdodCBiZSBjdXJ0YWls ZWQgdW50aWwgaGlzIG5leHQgSUVURiBhdHRlbmRhbmNlLg0KDQpUaGlzIGVtYWlsIG5vdyBiZWNv bWVzIGEgY2FsbCBmb3IgaW50ZXJlc3RlZCBwYXJ0aWVzIHdobyB3b3VsZCBsaWtlIHRvIGJlIGNv bnNpZGVyZWQgdG8gZmlsbCB0aGUgY28tY2hhaXIgcm9sZSBpbiBETlNTRC4NCg0KV2hhdCBJIGFt IGxvb2tpbmcgZm9yIGlzIHNvbWVvbmUgd2hvIGlzIE5PVCgqKSBzdHJvbmcgYW5kIHZlcnkgYWN0 aXZlIGNvbnRyaWJ1dG9yIHRvIHRoZSB3b3JrIGluIEROU1NELCBidXQgZG9lcyBhbHJlYWR5IGZv bGxvdyB0aGUgV0cgSXRlbXMgYW5kIHdoYXQgaXMgaGFwcGVuaW5nIGluIGFuZCBhcm91bmQgdGhl IHRlY2hub2xvZ3kgc3BhY2UuIEhhdmluZyBhIGdvb2QgYXdhcmVuZXNzIG9mIHdoYXQgaXMgaGFw cGVuaW5nIGluIERQUklWRSBhbmQgb3RoZXIgRE5TIHJlbGF0ZWQgV0dzIHdvdWxkIGJlIGFkdmFu dGFnZW91cy4gUHJldmlvdXMgZXhwZXJpZW5jZSBpbiBhbiBJRVRGIGxlYWRlcnNoaXAgcm9sZSAo d2hlcmUgeW91IGhhdmUgaGFkIHRvIGp1ZGdlIGNvbnNlbnN1cykgaXMgaW50ZXJlc3RpbmcgdG8g bWUgLSBidXQgaXMgY2VydGFpbmx5IG5vdCBtYW5kYXRvcnkuDQoNCigqKSAtIEkgYmVsaWV2ZSB0 aGUgcGVvcGxlIHdobyBhcmUgZG9pbmcgZ3JlYXQgd29yayBpbiBETlNTRCBuZWVkIHRvIGNvbnRp bnVlIHRvIGZvY3VzIG9uIGFuZCBkbyB0aGF0IGdyZWF0IHdvcmsuDQoNCklmIHlvdSBhcmUgaW50 ZXJlc3RlZCBpbiBiZWluZyBjb25zaWRlcmVkIGZvciB0aGlzIHJvbGUsIGFuZCBiZWxpZXZlIHlv dXIgc3BvbnNvciBPcmcgd2lsbCBzdXBwb3J0IHlvdSwgcGxlYXNlIGVtYWlsIG1lIGJ5IFN1bmRh eSA3cG0gMTV0aCBKdWx5IChNb250cmVhbCB0aW1lKSBhbmQgSSB3aWxsIHJlYWNoIG91dCB0byB5 b3UgYW5kIGVzdGFibGlzaCBhIHRpbWUgZm9yIGEgZGlzY3Vzc2lvbiBkdXJpbmcgSUVURiBXZWVr Lg0KDQpJbiB0aGUgY2FzZSB0aGVyZSBhcmUgbXVsdGlwbGUgY2FuZGlkYXRlcywgSSBwbGFuIHRv IG1ha2UgYSBkZWNpc2lvbiBieSB0aGUgMjd0aCBKdWx5Lg0KDQpUaGFua3MgYWxsLCBhbmQgdGhh bmtzIFRpbSENClRlcnJ5DQoNCg== From nobody Mon Jul 9 15:29:09 2018 Return-Path: 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 1FBB1130E80 for ; Mon, 9 Jul 2018 15:29:07 -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 aYhLQ-7JVAUX for ; Mon, 9 Jul 2018 15:29:03 -0700 (PDT) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 449FF130DC3 for ; Mon, 9 Jul 2018 15:29:03 -0700 (PDT) Received: by mail-qt0-x243.google.com with SMTP id b15-v6so16771970qtp.11 for ; Mon, 09 Jul 2018 15:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w7T2h3BwcwKaXCsyr+f3l81v15EBoIQjhzSdsMALehM=; b=yEy12WnqEre3ARjQ+Td1j+98UtMrRnj0wAGt7zKyNx3ah+L+ba0AepsBBYxSYECHaU BSdUGC7fDSx3fwBFeAj3yuy8DHfemQv/Of760qraGGGTB4nzpHBpM5Pyu3P3EPAK6qzl 2EQOB0z9QyZYR+KvFiBYf+inhtD2r031WYBm6Z/Jko7FX5w/a6kwXFHkLgjelRZTUEYr z5fdvNherZ6KkeexDimUBX7z3IZ/n2KWR3UYrGzY3Wro0Q7UofVFvd6e6sADqmtiIddW GD9gYO/FBME+g/f1x/dTKglIIS/tRRRY2x+ECCTAXRE52rNUnBjPFH8IBwnm4I3HSDah wkYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w7T2h3BwcwKaXCsyr+f3l81v15EBoIQjhzSdsMALehM=; b=KRQ4fn+im35CZ4Df1y7TrRmF1DaTZq1Ru584VzZAk3XgpzscqP2vEKZvWMIETPEIok EZY4dI0i2bdfSTqfQYl+NGLhe0voJeFEYGadZ/H+KfCS+PDAIoTVPhxsI8EADxa2/KYA qNJ0ZOfF9IQJ6ZV8oNEGVHkW4Wosa0mHiQbQWlGPAiqYTwQHuaIsu2VwhQqh7PI17gmt K1KR5RQ6Gv3G7/0xuMXU+DS3zlMIPgtaXuGIfjJXqS/9a7kDNlVJZDDzrl2iFQbyui0f n7UxBNS3oq6LVENhoICgsimtwFuNxd9/48hstYK9C+yKWpqAaa7Y1sa1TX60zYfr9FZe YwaA== X-Gm-Message-State: APt69E32Jmoo4dn8HTxBvGdqgC2Sv3Qom8pyuGRevZITgbBMsn7rIgMv 5oT/tQWjzz+mVcvTPsIOAi/KSGIsS4c= X-Google-Smtp-Source: AAOMgpd5oxvmZp4cqhuFsRLZp9TKbl2rl0fjD8Shku5uMwLO09emz5sChBAsRg9VAjoDlTHeZVJg5A== X-Received: by 2002:aed:2518:: with SMTP id v24-v6mr20909334qtc.151.1531175342281; Mon, 09 Jul 2018 15:29:02 -0700 (PDT) Received: from [10.0.100.12] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d39-v6sm13339093qta.60.2018.07.09.15.29.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 15:29:01 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D7156CD1-6D13-461B-9E08-F924CC2D0EB3" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.15\)) Date: Mon, 9 Jul 2018 18:29:00 -0400 In-Reply-To: <87in5td3ar.fsf@toke.dk> Cc: David Schinazi , dnssd To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.100.15) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 22:29:08 -0000 --Apple-Mail=_D7156CD1-6D13-461B-9E08-F924CC2D0EB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 5, 2018, at 1:02 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Yeah, I think Stuart explained this to me at some point. But I'm not > sure if "ask Stuart" is sufficiently discoverable, so mentioning it in > the document might be a good idea ;) Agreed. >>> - Address-based ACLs: Obviously, in most cases a client should only = be >>> able to perform registration if it is actually on the right network. >>> Firewalling off the ports from outside the relevant networks is a = way >>> to ensure this, but it is somewhat of a crude tool. For one, it >>> prevents a single registration server / proxy from serving multiple >>> networks[1]. For another, it prevents a use case where a client is = only >>> allowed *initial* registration (when the key is first cached) from >>> inside the network, but is allowed to subsequently update the same >>> record from anywhere. This is useful to, for instance, have my = laptop >>> maintain my-laptop.myhome.example.org even when visiting another >>> network. >>=20 >> That's a good point=E2=80=94I hadn't thought about enabling the = off-site >> update. There are security implications of that, of course: it could >> be a foothold for an informed attacker. I'm not convinced that it >> should be permitted by default, and indeed in the homenet scenario, >> for example, I would say that it should not be permitted by default. >> There may be scenarios where it makes sense. >=20 > Sure, by all means hide it behind a big "I know what I'm doing" = button, > or something. I just don't want the standard to rule out the = possibility > entirely. Sure. >>> So another way to ensure this source verification is needed, I = think. >>> The way I implemented it is to have the registration server only = speak >>> TCP; that way, source address spoofing is not possible (as that = would >>> make the handshake fail), and the server can simply implement a >>> straight-forward ACL policy. >>=20 >> This could also work, or we could use DNS cookies, but it breaks the >> LLN use case. >=20 > Wouldn't it be possible to specify both? I'm coming around to thinking this might be a good idea for some cases, = but I also think that the anycast use case needs to be preserved, and = that ought to be a simple two-message exchange in the success case. = The problem is deciding when TCP makes sense. I think there are three cases we should consider here: Homenet Campus net LLN In the case of Homenet, I think TCP works fine, except that we can = expect to see LLNs in most homenets going forward. So TCP doesn't = entirely work fine, and managing this edge case is tricky. We'd need = to define a heuristic for how the LLN edge router(s) validate updates = from the LLN. Actually, I think the Campus net case is pretty much the same. So = okay, that means that if we can figure out how to do one thing on LLNs = and another thing in all other cases, maybe that's the answer. I'd = just as soon avoid DNS cookies=E2=80=94they don't add any value over TCP = in this case as far as I know. We'd have to forbid 0RTT, because the = whole point of using TCP is to validate that the IP address that sent = the update can receive a reply. >>> - It is not quite clear to me whether the sleep proxy described in >>> section 4 is an optional feature or if its meant to be mandatory. >>> Stuart explained its usefulness for devices that power off when not = in >>> use, requiring this function will mean that registration servers = will >>> need to be on the local link, which is somewhat limiting. Also, the >>> implementation complexity goes way up (I certainly don't plan to >>> implement this feature :)). So I think having a way for the server = to >>> signal "no, I can't perform sleep proxying" to the client would be >>> good to allow things to fail in a graceful way. >>=20 >> Sleep proxy is advertised as a service, so devices that don't >> implement it can not advertise it. >=20 > Ah, great. As long as its in spec to not advertise that service, = that's > good enough for me. >=20 >> However, this breaks the LLN single-exchange use case, so I think >> there's an argument that it should be required on LLNs. >=20 > Hmm, I'm not sure I quite understand what you mean by single-exchange > use case, then? An LLN device should be able to register with a sleep proxy without = first discovering a specific sleep proxy with which to register. It = should IOW be able to send a single DNS Update packet to an anycast = address and get back a response of "yes, we have set up a sleep proxy = for you." > What I mean is that to do sleep proxying (as I read the spec) requires > raw sockets, or some other way to answer neighbour requests on the > sleeping device's behalf. Which generally tends to be a privileged > operation, and raises the complexity from "just answer DNS requests". > And of course it requires link-local presence, which means it either > requires automation (such as in homenet), or lots of manual > configuration. Right. This is actually a really key point that we'd utterly missed. = Since we are supporting multiple subnets, the current sleep proxy = paradigm doesn't work. That doesn't mean it _can't_ work, but it is = different than what we'd had in mind, and is in fact more work than we'd = been assuming. Thanks for poking a hole in this blind spot! I'm not sure what the answer is here=E2=80=94on a homenet it's not too = hard to imagine a solution; on an LLN I think it's not a problem, but = it's definitely a problem for the campus use case. I don't think this = is an impediment to adoption, because the registration protocol is = useful whether it supports the sleep proxy use case or not. But we = need to figure out how to address this. > I think it's not important enough to put in the effort to implement = it, > basically. >=20 > Note that this is for my use case; I can totally agree that requiring = it > for homenet makes sense; but service registration can be useful in = other > contexts as well... I'm curious if I've listed the contexts that you care about, or if I = missed some. What contexts do you have in mind?= --Apple-Mail=_D7156CD1-6D13-461B-9E08-F924CC2D0EB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 5, 2018, at 1:02 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> = wrote:
Yeah, I think Stuart explained this to me at some point. But = I'm not
sure if "ask Stuart" is sufficiently discoverable, = so mentioning it in
the document might be a good idea = ;)

Agreed.

- = Address-based ACLs: Obviously, in most cases a client should only be
able to perform registration if it is actually on the right = network.
Firewalling off the ports from outside the = relevant networks is a way
to ensure this, but it is = somewhat of a crude tool. For one, it
prevents a single = registration server / proxy from serving multiple
= networks[1]. For another, it prevents a use case where a client is = only
allowed *initial* registration (when the key is = first cached) from
inside the network, but is allowed to = subsequently update the same
record from anywhere. This = is useful to, for instance, have my laptop
maintain my-laptop.myhome.example.org even when visiting = another
network.

That's a good point=E2=80=94I hadn't thought about enabling = the off-site
update. There are security implications of = that, of course: it could
be a foothold for an informed = attacker. I'm not convinced that it
should be permitted by = default, and indeed in the homenet scenario,
for example, = I would say that it should not be permitted by default.
There may be scenarios where it makes sense.

Sure, by all means hide it behind = a big "I know what I'm doing" button,
or something. I just = don't want the standard to rule out the possibility
entirely.

Sure.

So = another way to ensure this source verification is needed, I think.
The way I implemented it is to have the registration server = only speak
TCP; that way, source address spoofing is not = possible (as that would
make the handshake fail), and the = server can simply implement a
straight-forward ACL = policy.

This could also work, = or we could use DNS cookies, but it breaks the
LLN use = case.

Wouldn't it be possible = to specify both?

I'm coming around to thinking this might be a good = idea for some cases, but I also think that the anycast use case needs to = be preserved, and that ought to be a simple two-message exchange in the = success case.   The problem is deciding when TCP makes = sense.

I think there are three cases = we should consider here:
  1. Homenet
  2. Campus net
  3. LLN
In the case of Homenet, I think = TCP works fine, except that we can expect to see LLNs in most homenets = going forward.   So TCP doesn't entirely work fine, and managing = this edge case is tricky.   We'd need to define a heuristic for how = the LLN edge router(s) validate updates from the LLN.

Actually, I think the = Campus net case is pretty much the same.   So okay, that means that = if we can figure out how to do one thing on LLNs and another thing in = all other cases, maybe that's the answer.   I'd just as soon avoid = DNS cookies=E2=80=94they don't add any value over TCP in this case as = far as I know.   We'd have to forbid 0RTT, because the whole point = of using TCP is to validate that the IP address that sent the update can = receive a reply.

- It is = not quite clear to me whether the sleep proxy described in
= section 4 is an optional feature or if its meant to be mandatory.
Stuart explained its usefulness for devices that power off = when not in
use, requiring this function will mean that = registration servers will
need to be on the local link, = which is somewhat limiting. Also, the
implementation = complexity goes way up (I certainly don't plan to
= implement this feature :)). So I think having a way for the server to
signal "no, I can't perform sleep proxying" to the client = would be
good to allow things to fail in a graceful = way.

Sleep proxy is advertised = as a service, so devices that don't
implement it can not = advertise it.

Ah, great. As = long as its in spec to not advertise that service, that's
good enough for me.

However, this breaks the LLN single-exchange = use case, so I think
there's an argument that it should be = required on LLNs.

Hmm, I'm not = sure I quite understand what you mean by single-exchange
use= case, then?

An LLN device should be able to register with a sleep = proxy without first discovering a specific sleep proxy with which to = register.   It should IOW be able to send a single DNS Update = packet to an anycast address and get back a response of "yes, we have = set up a sleep proxy for you."

What I mean is = that to do sleep proxying (as I read the spec) requires
raw = sockets, or some other way to answer neighbour requests on the
sleeping device's behalf. Which generally tends to be a = privileged
operation, and raises the complexity from "just = answer DNS requests".
And of course it requires link-local = presence, which means it either
requires automation (such = as in homenet), or lots of manual
configuration.

Right. =   This is actually a really key point that we'd utterly missed. =   Since we are supporting multiple subnets, the current sleep proxy = paradigm doesn't work.   That doesn't mean it _can't_ work, but it = is different than what we'd had in mind, and is in fact more work than = we'd been assuming.   Thanks for poking a hole in this blind = spot!

I'm not sure what the answer = is here=E2=80=94on a homenet it's not too hard to imagine a solution; on = an LLN I think it's not a problem, but it's definitely a problem for the = campus use case.   I don't think this is an impediment to adoption, = because the registration protocol is useful whether it supports the = sleep proxy use case or not.   But we need to figure out how to = address this.

I think it's = not important enough to put in the effort to implement it,
basically.

Note that this is for = my use case; I can totally agree that requiring it
for = homenet makes sense; but service registration can be useful in other
contexts as well...

I'm curious if I've listed the contexts that you care about, = or if I missed some.   What contexts do you have in = mind?
= --Apple-Mail=_D7156CD1-6D13-461B-9E08-F924CC2D0EB3-- From nobody Tue Jul 10 05:49:11 2018 Return-Path: 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 B4B5E131171 for ; Tue, 10 Jul 2018 05:49:00 -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 bsJTsG33j0Vk for ; Tue, 10 Jul 2018 05:48:54 -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 46D3313117A for ; Tue, 10 Jul 2018 05:48:54 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531226930; bh=VueVB+pKfzPygwEoplOS8V6644X6Q9rZfhTO5ywpLsw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NeDRV+s/UHdEns7IbLMzwz4KN1p3yy/HGaMMedgUXjAzuVqs1qcrUiA6yeEq2btou 7UYOWt5Ekc5w4GeivAaEntpppAt+krjFuS9o/E1TnipnkEyCexOcDmpBGu3nDUfs22 PxR94fo1/amQFghg0T6OMS6pC3zFGHZETRC/nZqURsPkRPeTbO5dI4+sEWSJ5fOa1D kgcgtfEmhNSgvEZrXWfCLqRDIiFCXOY6DLfYldovksMZt6/LNE/arMnoRF1CACX+tk A+OI2qNiXNFRK3By2C935l/+nHTcn4gkC7tnq71leF1rBQ3MvgQFn5ODBPdjs8P5EQ ikhTW6ps97qlg== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> Date: Tue, 10 Jul 2018 14:48:50 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r2kbcl3h.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 12:49:07 -0000 Ted Lemon writes: >>>> So another way to ensure this source verification is needed, I think. >>>> The way I implemented it is to have the registration server only speak >>>> TCP; that way, source address spoofing is not possible (as that would >>>> make the handshake fail), and the server can simply implement a >>>> straight-forward ACL policy. >>>=20 >>> This could also work, or we could use DNS cookies, but it breaks the >>> LLN use case. >>=20 >> Wouldn't it be possible to specify both? > > I'm coming around to thinking this might be a good idea for some > cases, but I also think that the anycast use case needs to be > preserved, and that ought to be a simple two-message exchange in the > success case. The problem is deciding when TCP makes sense. Couldn't that just be left up to the client? I.e., the network SHOULD provide both, clients MUST support both and if the network only supports one use that; but if the network supports both, the client is free to pick whatever makes the most sense for its use case. I'm a little worried that this would lead to too many permutations to test interoperability, and/or just lead to cherry-picking. But it's definitely easier to specify than coming up for rules for when to do what... :) >>>> - It is not quite clear to me whether the sleep proxy described in >>>> section 4 is an optional feature or if its meant to be mandatory. >>>> Stuart explained its usefulness for devices that power off when not in >>>> use, requiring this function will mean that registration servers will >>>> need to be on the local link, which is somewhat limiting. Also, the >>>> implementation complexity goes way up (I certainly don't plan to >>>> implement this feature :)). So I think having a way for the server to >>>> signal "no, I can't perform sleep proxying" to the client would be >>>> good to allow things to fail in a graceful way. >>>=20 >>> Sleep proxy is advertised as a service, so devices that don't >>> implement it can not advertise it. >>=20 >> Ah, great. As long as its in spec to not advertise that service, that's >> good enough for me. >>=20 >>> However, this breaks the LLN single-exchange use case, so I think >>> there's an argument that it should be required on LLNs. >>=20 >> Hmm, I'm not sure I quite understand what you mean by single-exchange >> use case, then? > > An LLN device should be able to register with a sleep proxy without > first discovering a specific sleep proxy with which to register. It > should IOW be able to send a single DNS Update packet to an anycast > address and get back a response of "yes, we have set up a sleep proxy > for you." Right. And how is it supposed to discover which anycast address to use? Or is that going to be a special address assigned as part of the standard? >> What I mean is that to do sleep proxying (as I read the spec) requires >> raw sockets, or some other way to answer neighbour requests on the >> sleeping device's behalf. Which generally tends to be a privileged >> operation, and raises the complexity from "just answer DNS requests". >> And of course it requires link-local presence, which means it either >> requires automation (such as in homenet), or lots of manual >> configuration. > > Right. This is actually a really key point that we'd utterly missed. > Since we are supporting multiple subnets, the current sleep proxy > paradigm doesn't work. That doesn't mean it _can't_ work, but it is > different than what we'd had in mind, and is in fact more work than > we'd been assuming. Thanks for poking a hole in this blind spot! Haha, you're welcome ;) > I'm not sure what the answer is here=E2=80=94on a homenet it's not too ha= rd to > imagine a solution; on an LLN I think it's not a problem, but it's > definitely a problem for the campus use case. I don't think this is an > impediment to adoption, because the registration protocol is useful > whether it supports the sleep proxy use case or not. Agreed. > But we need to figure out how to address this. Hmm, only thing that comes to mind is doing the proxying at layer 3 instead; i.e., advertise the proxy's address in DNS and forward packets to the sleeping device using encapsulation or (*shudder*) two-way NAT. That would require the proxy to stay in the loop for everything to be transparent, though, so not sure if it's a good solution... >> I think it's not important enough to put in the effort to implement it, >> basically. >>=20 >> Note that this is for my use case; I can totally agree that requiring it >> for homenet makes sense; but service registration can be useful in other >> contexts as well... > > I'm curious if I've listed the contexts that you care about, or if I > missed some. What contexts do you have in mind? I think my use case is covered by the campus use case, more or less. I.e., a managed network where devices should be able to register themselves automatically in (global) DNS with a minimum of configuration. I use it to find devices on my network; if I just configure devices to run the registration daemon, and put the right discovery PTR records in the network-local recursive resolver, I will be able to find them by hostname on the local link, and the registration server can be configured to (selectively) put things into global DNS as well. Since I run this on different networks, I run registration proxy in the cloud, where it services several networks (with different domain names). So anything that requires link-local presence is a hassle to support... -Toke From nobody Wed Jul 11 21:10:54 2018 Return-Path: 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 70580130EC6 for ; Wed, 11 Jul 2018 21:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 OUxpWA1wIy0v for ; Wed, 11 Jul 2018 21:10:49 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 711CA130DE8 for ; Wed, 11 Jul 2018 21:10:49 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p185-v6so5146129itp.4 for ; Wed, 11 Jul 2018 21:10:49 -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=xjSdUI+4Jv9dVQU7zpq3v9c/p/E6iK1yDSu5RmgViAI=; b=FVccYQNJNv2wIMMUyo9ZCJmjR9BuyNX99jG8IzIuu/xydYWRsqYkQiO7TLIiftY6m6 llVpHPxu3KKui6oD0D2C/JVFs/DTzXMq/PXwqMiW4KrJhH/QwmCc7PTMw7xZ09NS4b7E g8uzPMF1Wm03PgdoSU6LezDLdNv6y0bfghZ+hHgcWmQPcVakjuRB5mC42eVuHIBLwCDF I42EgyHlIRx13jcmIJ7o8E9ulYccZwqs0W51Sz4/byysTpCUS1jVT7Mqpt2IF5/FmLq+ JHLgxL8kQQtvx0XMLL7zEsnib1jhDMh2sPyvhjcRof8YW4to+1leOH7x7RJIVG/1A6ik NJdw== 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=xjSdUI+4Jv9dVQU7zpq3v9c/p/E6iK1yDSu5RmgViAI=; b=sIis3aoXBeHA8LTGkn8XfejxMFPwm7/dLx5oCX4QIXVR7KDMXjsjQMACTnCdUpORiY 7xQ7GVtelD4tyTp36OiadAEGyC2azMc4A2xqnTdlZlKrwqOwGDerKh+0fozP1DmY/AlW neo+OU7TMHBjZHdISlBP2XaYRrzu2XvJsCpRdqaLnKqk/zCndkRgYQzFDDDCAf+Hy9pB i5BdEn75GM+Qu8F7vAqOYcaJIwTezCb2/kelOnu6zafwrmbjrXcE8i7O95sReY35NVl0 RyT0+cz8TlT310Saehv/qNUOMdKTe3/jXoUbMfDJ/tBEjjjX/Yd2sBImq3hrh1ir887J HtpA== X-Gm-Message-State: AOUpUlHzW9N8ihtRDinylsnRPFA3Aidih42YOPYmO8BznQ9IONZVhuA7 v2I09umap68fZhGMdDYUBIWTegOrIoyxXKknpC2zWQ== X-Google-Smtp-Source: AAOMgpcv3vqAxMByxfdit9wlhQySyrrx3ETUdZR+COkjNQ7JYHVwHRBZUYRL1HNY9mXZJk56306pOvdVgAMGQQJO8vg= X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr188970itb.144.1531368648695; Wed, 11 Jul 2018 21:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 21:10:08 -0700 (PDT) In-Reply-To: <87r2kbcl3h.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 00:10:08 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="0000000000005381710570c58c94" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 04:10:54 -0000 --0000000000005381710570c58c94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. You can see the diffs here: https://github.com/StuartCheshire/draft-sctl-service-registration/commit/51= b7cb54300fea7e44e8e7dee49c17e9f598b3ba The text of the document is here: https://github.com/StuartCheshire/draft-sctl-service-registration/blob/mast= er/draft-sctl-service-registration.txt I don't think this substantially changes what we'll discuss in Montreal, but attendees who want to give technical feedback at the mic should probably read this version. On Tue, Jul 10, 2018 at 8:48 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > >>>> So another way to ensure this source verification is needed, I think= . > >>>> The way I implemented it is to have the registration server only spe= ak > >>>> TCP; that way, source address spoofing is not possible (as that woul= d > >>>> make the handshake fail), and the server can simply implement a > >>>> straight-forward ACL policy. > >>> > >>> This could also work, or we could use DNS cookies, but it breaks the > >>> LLN use case. > >> > >> Wouldn't it be possible to specify both? > > > > I'm coming around to thinking this might be a good idea for some > > cases, but I also think that the anycast use case needs to be > > preserved, and that ought to be a simple two-message exchange in the > > success case. The problem is deciding when TCP makes sense. > > Couldn't that just be left up to the client? I.e., the network SHOULD > provide both, clients MUST support both and if the network only supports > one use that; but if the network supports both, the client is free to > pick whatever makes the most sense for its use case. > > I'm a little worried that this would lead to too many permutations to > test interoperability, and/or just lead to cherry-picking. But it's > definitely easier to specify than coming up for rules for when to do > what... :) > > >>>> - It is not quite clear to me whether the sleep proxy described in > >>>> section 4 is an optional feature or if its meant to be mandatory. > >>>> Stuart explained its usefulness for devices that power off when not = in > >>>> use, requiring this function will mean that registration servers wil= l > >>>> need to be on the local link, which is somewhat limiting. Also, the > >>>> implementation complexity goes way up (I certainly don't plan to > >>>> implement this feature :)). So I think having a way for the server t= o > >>>> signal "no, I can't perform sleep proxying" to the client would be > >>>> good to allow things to fail in a graceful way. > >>> > >>> Sleep proxy is advertised as a service, so devices that don't > >>> implement it can not advertise it. > >> > >> Ah, great. As long as its in spec to not advertise that service, that'= s > >> good enough for me. > >> > >>> However, this breaks the LLN single-exchange use case, so I think > >>> there's an argument that it should be required on LLNs. > >> > >> Hmm, I'm not sure I quite understand what you mean by single-exchange > >> use case, then? > > > > An LLN device should be able to register with a sleep proxy without > > first discovering a specific sleep proxy with which to register. It > > should IOW be able to send a single DNS Update packet to an anycast > > address and get back a response of "yes, we have set up a sleep proxy > > for you." > > Right. And how is it supposed to discover which anycast address to use? > Or is that going to be a special address assigned as part of the > standard? > > >> What I mean is that to do sleep proxying (as I read the spec) requires > >> raw sockets, or some other way to answer neighbour requests on the > >> sleeping device's behalf. Which generally tends to be a privileged > >> operation, and raises the complexity from "just answer DNS requests". > >> And of course it requires link-local presence, which means it either > >> requires automation (such as in homenet), or lots of manual > >> configuration. > > > > Right. This is actually a really key point that we'd utterly missed. > > Since we are supporting multiple subnets, the current sleep proxy > > paradigm doesn't work. That doesn't mean it _can't_ work, but it is > > different than what we'd had in mind, and is in fact more work than > > we'd been assuming. Thanks for poking a hole in this blind spot! > > Haha, you're welcome ;) > > > I'm not sure what the answer is here=E2=80=94on a homenet it's not too = hard to > > imagine a solution; on an LLN I think it's not a problem, but it's > > definitely a problem for the campus use case. I don't think this is an > > impediment to adoption, because the registration protocol is useful > > whether it supports the sleep proxy use case or not. > > Agreed. > > > But we need to figure out how to address this. > > Hmm, only thing that comes to mind is doing the proxying at layer 3 > instead; i.e., advertise the proxy's address in DNS and forward packets > to the sleeping device using encapsulation or (*shudder*) two-way NAT. > That would require the proxy to stay in the loop for everything to be > transparent, though, so not sure if it's a good solution... > > >> I think it's not important enough to put in the effort to implement it= , > >> basically. > >> > >> Note that this is for my use case; I can totally agree that requiring = it > >> for homenet makes sense; but service registration can be useful in oth= er > >> contexts as well... > > > > I'm curious if I've listed the contexts that you care about, or if I > > missed some. What contexts do you have in mind? > > I think my use case is covered by the campus use case, more or less. > I.e., a managed network where devices should be able to register > themselves automatically in (global) DNS with a minimum of > configuration. > > I use it to find devices on my network; if I just configure devices to > run the registration daemon, and put the right discovery PTR records in > the network-local recursive resolver, I will be able to find them by > hostname on the local link, and the registration server can be > configured to (selectively) put things into global DNS as well. Since > I run this on different networks, I run registration proxy in the cloud, > where it services several networks (with different domain names). So > anything that requires link-local presence is a hassle to support... > > -Toke > --0000000000005381710570c58c94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just did a somewhat larger-than-expected update to the d= ocument to capture Toke's comments thus far.=C2=A0 =C2=A0I also got a s= urprise guest review from a friend of mine, Tamara Kemper, who revealed a f= ew opportunities to make the document clearer and better scoped.=C2=A0 In t= he process of doing these two things I noticed that I'd fairly signific= antly misstated how SRV records work and left out some important details.= =C2=A0 =C2=A0The new document fixes all of these things (I hope).=C2=A0 =C2= =A0Sorry 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 late= r.=C2=A0 The good news is that I'm pretty chuffed about the quality of = the document now.


I don't think this substantially change= s what we'll discuss in Montreal, but attendees who want to give techni= cal feedback at the mic should probably read this version.

On Tue, Jul 10, 2018 a= t 8:48 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrot= e:
Ted Lemon <mellon@fugue.com> writes:

>>>> So another way to ensure this source verification is neede= d, I think.
>>>> The way I implemented it is to have the registration serve= r only speak
>>>> TCP; that way, source address spoofing is not possible (as= that would
>>>> make the handshake fail), and the server can simply implem= ent a
>>>> straight-forward ACL policy.
>>>
>>> This could also work, or we could use DNS cookies, but it brea= ks the
>>> LLN use case.
>>
>> Wouldn't it be possible to specify both?
>
> I'm coming around to thinking this might be a good idea for some > cases, but I also think that the anycast use case needs to be
> preserved, and that ought to be a simple two-message exchange in the > success case. The problem is deciding when TCP makes sense.

Couldn't that just be left up to the client? I.e., the network SHOULD provide both, clients MUST support both and if the network only supports one use that; but if the network supports both, the client is free to
pick whatever makes the most sense for its use case.

I'm a little worried that this would lead to too many permutations to test interoperability, and/or just lead to cherry-picking. But it's
definitely easier to specify than coming up for rules for when to do
what... :)

>>>> - It is not quite clear to me whether the sleep proxy desc= ribed in
>>>> section 4 is an optional feature or if its meant to be man= datory.
>>>> Stuart explained its usefulness for devices that power off= when not in
>>>> use, requiring this function will mean that registration s= ervers will
>>>> need to be on the local link, which is somewhat limiting. = Also, the
>>>> implementation complexity goes way up (I certainly don'= ;t plan to
>>>> implement this feature :)). So I think having a way for th= e server to
>>>> signal "no, I can't perform sleep proxying" = to the client would be
>>>> good to allow things to fail in a graceful way.
>>>
>>> Sleep proxy is advertised as a service, so devices that don= 9;t
>>> implement it can not advertise it.
>>
>> Ah, great. As long as its in spec to not advertise that service, t= hat's
>> good enough for me.
>>
>>> However, this breaks the LLN single-exchange use case, so I th= ink
>>> there's an argument that it should be required on LLNs. >>
>> Hmm, I'm not sure I quite understand what you mean by single-e= xchange
>> use case, then?
>
> An LLN device should be able to register with a sleep proxy without > first discovering a specific sleep proxy with which to register. It > should IOW be able to send a single DNS Update packet to an anycast > address and get back a response of "yes, we have set up a sleep p= roxy
> for you."

Right. And how is it supposed to discover which anycast address to use?
Or is that going to be a special address assigned as part of the
standard?

>> What I mean is that to do sleep proxying (as I read the spec) requ= ires
>> raw sockets, or some other way to answer neighbour requests on the=
>> sleeping device's behalf. Which generally tends to be a privil= eged
>> operation, and raises the complexity from "just answer DNS re= quests".
>> And of course it requires link-local presence, which means it eith= er
>> requires automation (such as in homenet), or lots of manual
>> configuration.
>
> Right. This is actually a really key point that we'd utterly misse= d.
> Since we are supporting multiple subnets, the current sleep proxy
> paradigm doesn't work. That doesn't mean it _can't_ work, = but it is
> different than what we'd had in mind, and is in fact more work tha= n
> we'd been assuming. Thanks for poking a hole in this blind spot!
Haha, you're welcome ;)

> I'm not sure what the answer is here=E2=80=94on a homenet it's= not too hard to
> imagine a solution; on an LLN I think it's not a problem, but it&#= 39;s
> definitely a problem for the campus use case. I don't think this i= s an
> impediment to adoption, because the registration protocol is useful > whether it supports the sleep proxy use case or not.

Agreed.

> But we need to figure out how to address this.

Hmm, only thing that comes to mind is doing the proxying at layer 3
instead; i.e., advertise the proxy's address in DNS and forward packets=
to the sleeping device using encapsulation or (*shudder*) two-way NAT.
That would require the proxy to stay in the loop for everything to be
transparent, though, so not sure if it's a good solution...

>> I think it's not important enough to put in the effort to impl= ement it,
>> basically.
>>
>> Note that this is for my use case; I can totally agree that requir= ing it
>> for homenet makes sense; but service registration can be useful in= other
>> contexts as well...
>
> I'm curious if I've listed the contexts that you care about, o= r if I
> missed some. What contexts do you have in mind?

I think my use case is covered by the campus use case, more or less.
I.e., a managed network where devices should be able to register
themselves automatically in (global) DNS with a minimum of
configuration.

I use it to find devices on my network; if I just configure devices to
run the registration daemon, and put the right discovery PTR records in
the network-local recursive resolver, I will be able to find them by
hostname on the local link, and the registration server can be
configured to (selectively) put things into global DNS as well. Since
I run this on different networks, I run registration proxy in the cloud, where it services several networks (with different domain names). So
anything that requires link-local presence is a hassle to support...

-Toke

--0000000000005381710570c58c94-- From nobody Thu Jul 12 03:40:39 2018 Return-Path: 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 ; 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 ; 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 ; Thu, 12 Jul 2018 03:40:34 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= 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 Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 10:40:38 -0000 Ted Lemon 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 From nobody Thu Jul 12 06:25:59 2018 Return-Path: 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 E09AB130F15 for ; Thu, 12 Jul 2018 06:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 5VzsLPzYfDkg for ; Thu, 12 Jul 2018 06:25:54 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 5138E130F14 for ; Thu, 12 Jul 2018 06:25:54 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id h2-v6so4966067itj.1 for ; Thu, 12 Jul 2018 06:25:54 -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=0PYwzOWYdElnGqyIQpmW+eF+UFtkWr2DvlxwiGADzgg=; b=qZwFm8Q6QKixdSmJXwoDiDtsaVQT7Ql0SDdkvAeQOPoKw1Lbg/avu3LBdtefnF8cTv 4YOeZwJzJogDyATQ4yu3dMwH7zyHxfeQCaiuzMiUMVdgHfAxR63TaHbJjtVIomy5JPzw 9DNgQnXL3vuuMK98jtb4i9vTz1vLeLoLAvyy1vbzaabHGK6P0XpOW0JQWPCfTcLn8x6f nwntUycPN0hxXkcXsvbi4hmba3xAFNGHOzQRmUjkUNwplApOAtA6DfRGbjoylREe0HNO sbk/B7NC6OmBkJnJlaCZNvo+1XVvY3N1JgfXaOXaCWJVfuaSTB+AHHNwjzaXsW0WknyX iLaQ== 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=0PYwzOWYdElnGqyIQpmW+eF+UFtkWr2DvlxwiGADzgg=; b=hfyY7965VFoTvPe4tGuC35Hqb0Hp/wd4FlISiQOICwBKF9o/pOZR4xCjsOTNmwd5mJ ue+bgomK7UoTSZulPd5BV+9SA/A/KmXsUp9sm78FaD6/sXwz42k253tk3RTPm1sRdmKU D2tyowzXYQkpRoEi3wRn/lvFiV7LDGSxgqY/j0brpliNygN3uTqkrTI8ye30PAQTCSd8 E2ii2EsBmFJzPBAxppsW+TDpWn3Z5QP3KdWbY3VEuF4cZddZx8luWGEQqgwhqrK+7iwo YIVJb4fuRkRLofymHiKEn9xbE5n0OEdLjboIKiFNFgju8BuKbnnO5OVOlz1m2ygzPbsJ EabA== X-Gm-Message-State: AOUpUlFPbI97a8s4nOgYmdcfNHfGFJSamuhFoFKgsl3IZREAiZ1HVXJ3 68IbOPwkRJszhnAuuEOc6Q9W1ZVJIhacShoyp6mGAg== X-Google-Smtp-Source: AAOMgpeZhVoiiS/9SGg8rdFokOqKxDKkEbPhXVQ1Qb9XYta1Tuc3ZIGhbeLXDF9svAdvoRJpRfcGULhbkKzOEVpajMY= X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr1271194itb.144.1531401953647; Thu, 12 Jul 2018 06:25:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 06:25:13 -0700 (PDT) In-Reply-To: <87fu0obuua.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 09:25:13 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="00000000000074b5420570cd4d4c" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 13:25:57 -0000 --00000000000074b5420570cd4d4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2018 at 6:40 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Thanks for the update! I think this version addresses my concerns from > the previous round. :) > Great! > 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? > I think that that's up to the implementation. It could do it based on IP address, or as I suggested in the document it could have a whitelist that's maintained by an administrator, based on the key or the name or the service type. As long as it does the same thing every time, the details are (I think) immaterial. However, this is worth thinking about=E2=80=94if you c= an come up with something that doesn't work, we should document it. > - 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... > Interesting. I did it this way because I don't want to get into the "PTR is bad, get rid of it, no it's good, I want it" argument. :) It could certainly be a site policy to auto-add a PTR record. Since the content of the PTR record is fixed, this would just have the effect of making PTR records non-optional, not of changing what got stored in the update. I would be in favor of adding this as an optional behavior. However, I think that this should be optional behavior, and therefore I think it's worth allowing the client to update the PTR record. The benefit of this is that it gives the software/hardware vendor some say in what debugging information is available, regardless of the opinions of the network operator or DNS server implementor. - 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? > Can you think of a scenario where it makes sense to do this? The reason that this might not be permissible is simply that I can't think of a record other than the PTR record that could be omitted without making things fail. > - 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? Unless they are modified. The point of that is not to suggest that implementing this is REQUIRED, but it could be useful for someone, and hence is not FORBIDDEN. If you think the text reads as making this a required feature, we should fix that! :) --00000000000074b5420570cd4d4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 12, 2018 at 6:40 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
Thanks for the update!= I think this version addresses my concerns from
the previous round. :)

Great!
=C2=A0=
A few other comments based on a quick read-through:

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

I think= that that's up to the implementation.=C2=A0 It could do it based on IP= address, or as I suggested in the document it could have a whitelist that&= #39;s maintained by an administrator, based on the key or the name or the s= ervice type.=C2=A0 =C2=A0As long as it does the same thing every time, the = details are (I think) immaterial.=C2=A0 =C2=A0However, this is worth thinki= ng about=E2=80=94if you can come up with something that doesn't work, w= e should document it.
=C2=A0
= - The document says that clients must generate their own reverse PTR
=C2=A0 records. Should the server be able to do that on the clients behalf?=
=C2=A0 It may be a matter of policy which ranges have reverse domain
=C2=A0 delegations...

Interesting.=C2= =A0 =C2=A0I did it this way because I don't want to get into the "= PTR is bad, get rid of it, no it's good, I want it" argument. :)

It could certainly be a site policy to auto-add a P= TR record.=C2=A0 =C2=A0Since the content of the PTR record is fixed, this w= ould just have the effect of making PTR records non-optional, not of changi= ng what got stored in the update.=C2=A0 =C2=A0I would be in favor of adding= this as an optional behavior.

However, I think th= at this should be optional behavior, and therefore I think it's worth a= llowing the client to update the PTR record.=C2=A0 =C2=A0The benefit of thi= s is that it gives the software/hardware vendor some say in what debugging = information is available, regardless of the opinions of the network operato= r or DNS server implementor.

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

Can you think of a s= cenario where it makes sense to do this?=C2=A0 =C2=A0The reason that this m= ight not be permissible is simply that I can't think of a record other = than the PTR record that could be omitted without making things fail.
=
=C2=A0
- You mention in the text t= hat a network may use a different domain than
=C2=A0 ip6.arpa for reverse PTRs. How does that work? Won't clients alw= ays
=C2=A0 do reverse lookups to ip6.arpa?

Unle= ss they are modified.=C2=A0 =C2=A0The point of that is not to suggest that = implementing this is REQUIRED, but it could be useful for someone, and henc= e is not FORBIDDEN.=C2=A0 If you think the text reads as making this a requ= ired feature, we should fix that!=C2=A0 =C2=A0:)=C2=A0

--00000000000074b5420570cd4d4c-- From nobody Thu Jul 12 08:10:22 2018 Return-Path: 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 C6F93130E52 for ; Thu, 12 Jul 2018 08:10:20 -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 08IxFtppfO5s for ; Thu, 12 Jul 2018 08:10:18 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38645130E00 for ; Thu, 12 Jul 2018 08:10:18 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531408209; bh=jYXn/KlTBlCT+S/t8OEIfuN07hDFI0KbmYwjhLwo/3Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cWhZPUhN42caQsnlr8jkGwkQnlg6/EL5BpYE2j4sHw5FS68ZtduI+a6kNA6MtIJaU p8+vCiUJNfwteZgyavVl2EN6WPn8DMqfaFbv/mE8n6yUGU6Qj6VChz4rThIAn1l/Oc YdhLPz3JmT+pOnFNv/dkFw84CnmU7kO6Z9uqbJSNcim0n9EqHkvYHIVP4ju4ZfUvS8 qirY7u9solBbS9bYq5bDzSdTZPEawAeSyuDknrhdOLLK9N2ClwJ8rzpa1qjnEwX+0C D29X+TVeuZGKvS5s1gJtlmzZT1Mt53BJxpVMaHsvwlBYfCuEjTziXmYAE5Xv9+9DYq 0q47hToDCY/BQ== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> Date: Thu, 12 Jul 2018 17:10:06 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874lh4bicx.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 15:10:21 -0000 Ted Lemon writes: >> 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? >> > > I think that that's up to the implementation. It could do it based on > IP address, or as I suggested in the document it could have a > whitelist that's maintained by an administrator, based on the key or > the name or the service type. As long as it does the same thing every > time, the details are (I think) immaterial. However, this is worth > thinking about=E2=80=94if you can come up with something that doesn't wor= k, we > should document it. Right. I *think* that will work; but will probably have to try it out to be sure :) >> - 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... >> > > Interesting. I did it this way because I don't want to get into the > "PTR is bad, get rid of it, no it's good, I want it" argument. :) I'm fine with not having that argument; just want to make sure the standard doesn't disallow it (auto-adding). See below. > - 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? >> > > Can you think of a scenario where it makes sense to do this? The > reason that this might not be permissible is simply that I can't think > of a record other than the PTR record that could be omitted without > making things fail. What I implemented is that the client will add AAAA records for all addresses assigned to the interface; and the registration server will filter out the ones it doesn't like (mostly making sure site-local addresses don't end up in global DNS). I think this sort of thing should be allowed at the server side (could also be a policy like "we don't want printers on this network"). The question is if the client should be notified; my server will tell the client which records were actually created, and the client won't bother maintaining the ones that weren't. However, this is mostly an optimisation; not sure if it's worth specifying in the spec... >> - 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? > > Unless they are modified. Right, that's what I thought. > The point of that is not to suggest that implementing this is > REQUIRED, but it could be useful for someone, and hence is not > FORBIDDEN. If you think the text reads as making this a required > feature, we should fix that! :) Hmm, don't think it read like it's required, necessarily; I was just confused by it. I consider(ed) the reverse domains a static thing not likely to change, in which case it seems odd to do the mapping from .local. Is this what happens in mDNS? -Toke From nobody Thu Jul 12 11:00:07 2018 Return-Path: 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 76D56131151 for ; Thu, 12 Jul 2018 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 e8LkZi_j33bA for ; Thu, 12 Jul 2018 11:00:01 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 9AD00131150 for ; Thu, 12 Jul 2018 11:00:01 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id s7-v6so8034406itb.4 for ; Thu, 12 Jul 2018 11:00:01 -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=LWrwYKEzdvq/8d/QdymhGF467Y3xmX2YsecRNVd6IBg=; b=nAIS1XlGp+yeYtCqAFPW20DhjVADENmei1aK/oNwH+gaAFnSoorDdlSfcVLcf9u2Fr T8QQlUv+K0XvLSRMfU3S/KaXF97GPgWz2ZVOvzI5Bk3UneJlziItlGmUpdjCQ2NyO3ia 0Akn3X3H8lharTbANBpdLXi79/UepqHLq8qdP0oHNHStOjGMb/Eev96QQW4ZHIzIqqUb JkAdSe71Ezz4k9o8I5WwWMGIxIadena+Ul1KHB8rWuILkEW7zlgnMoVg4LMwnyRohfIk OVL5jmln9Zc/q0lAyDvFu9Oi+111KfK1Y55x1VejA1T39sjyxIzqdfRWhl0QuSPnBW4Z ZC7w== 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=LWrwYKEzdvq/8d/QdymhGF467Y3xmX2YsecRNVd6IBg=; b=t394nSIDhWNqq2QI2ha3pXqaPZCRysxDxjaDhWXPr6jh/bmd+X/3ktxqouFDAB5Tqw 5az9Ogd1pt6a/0Q92PUxgBk2qnuD9IcQ871JVF/ij46eiIOY99zU792n5UT+cu7HmpP8 BV3hHaXwfEMkSMLmRDtljJA0yD3jAAi1+ryUAaD1/Lz4yjVSiLb3kW1WrjvsEmckpxJE aEIcCq9JQ4k0NbcVQTQdskXdOGxZbEkM4rHL7yqUr+NfXBZ0uY5MyD0PJUZMoh9iEQ7M B/17NzI6iv5OKLH94D8UY5iXoWArgK12ZPHDNAdJeguvh0S6E9e06SJxcSS8Z3U2Jc+r r9tA== X-Gm-Message-State: AOUpUlGL2vjj5OIm0J83fysegLvfH64gJZYwkSIwUwMW1xh8LnNYaN/x pcCnKd3UHJbbQKx3WG7xCI4ET/SIOZoah3XYkpFIOA== X-Google-Smtp-Source: AAOMgpfJfbeTchwKGkICEPdDylfHJsIGg7L77f1TTd7CAdWvtCHy8Jnj+iFDVjK4YScdHjIX4xGKtlh5qY4WiK8tZCE= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr2256178itg.82.1531418400935; Thu, 12 Jul 2018 11:00:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 10:59:20 -0700 (PDT) In-Reply-To: <874lh4bicx.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 13:59:20 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="000000000000ca6c540570d12131" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:00:05 -0000 --000000000000ca6c540570d12131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like the client should just keep maintaining whatever records it maintains. If the server doesn't take some updates, then the client can just keep trying. Otherwise the client has to somehow model the state of the server, which seems unnecessary. As for A and AAAA records, this is an open question: how to handle it. Is it a problem to allow a client to update arbitrary A and AAAA records? The restriction of only updating the one that corresponds to the source address used to send the update is there because we have some reasonable assurance that the client actually has that address. We could have some hack where we use the neighbor table to notice that several addresses are associated with the same layer 2 address, but that seems like not what we want to do. mDNS seems to just use .arpa. I don't know how/if that works, but I definitely don't see how to make it work with the DNS protocol. Maybe mDNSResponder caches this information and then returns it for 1918 networks and ULA networks, I don't know. On Thu, Jul 12, 2018 at 11:10 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > >> 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? > >> > > > > I think that that's up to the implementation. It could do it based on > > IP address, or as I suggested in the document it could have a > > whitelist that's maintained by an administrator, based on the key or > > the name or the service type. As long as it does the same thing every > > time, the details are (I think) immaterial. However, this is worth > > thinking about=E2=80=94if you can come up with something that doesn't w= ork, we > > should document it. > > Right. I *think* that will work; but will probably have to try it out to > be sure :) > > >> - 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... > >> > > > > Interesting. I did it this way because I don't want to get into the > > "PTR is bad, get rid of it, no it's good, I want it" argument. :) > > I'm fine with not having that argument; just want to make sure the > standard doesn't disallow it (auto-adding). See below. > > > - 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 who= le > >> registration if a subset is not admissible. If the server *is* allow= ed > >> to modify things, should it communicate back to the client what it > >> really did? > >> > > > > Can you think of a scenario where it makes sense to do this? The > > reason that this might not be permissible is simply that I can't think > > of a record other than the PTR record that could be omitted without > > making things fail. > > What I implemented is that the client will add AAAA records for all > addresses assigned to the interface; and the registration server will > filter out the ones it doesn't like (mostly making sure site-local > addresses don't end up in global DNS). I think this sort of thing should > be allowed at the server side (could also be a policy like "we don't > want printers on this network"). > > The question is if the client should be notified; my server will tell > the client which records were actually created, and the client won't > bother maintaining the ones that weren't. However, this is mostly an > optimisation; not sure if it's worth specifying in the spec... > > >> - You mention in the text that a network may use a different domain th= an > >> ip6.arpa for reverse PTRs. How does that work? Won't clients always > >> do reverse lookups to ip6.arpa? > > > > Unless they are modified. > > Right, that's what I thought. > > > The point of that is not to suggest that implementing this is > > REQUIRED, but it could be useful for someone, and hence is not > > FORBIDDEN. If you think the text reads as making this a required > > feature, we should fix that! :) > > Hmm, don't think it read like it's required, necessarily; I was just > confused by it. I consider(ed) the reverse domains a static thing not > likely to change, in which case it seems odd to do the mapping from > .local. Is this what happens in mDNS? > > -Toke > --000000000000ca6c540570d12131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like the client should just keep maintaining what= ever records it maintains.=C2=A0 =C2=A0If the server doesn't take some = updates, then the client can just keep trying.=C2=A0 =C2=A0Otherwise the cl= ient has to somehow model the state of the server, which seems unnecessary.=

As for A and AAAA records, this is an open question: ho= w to handle it.=C2=A0 =C2=A0Is it a problem to allow a client to update arb= itrary A and AAAA records?=C2=A0 =C2=A0The restriction of only updating the= one that corresponds to the source address used to send the update is ther= e because we have some reasonable assurance that the client actually has th= at address.=C2=A0 =C2=A0We could have some hack where we use the neighbor t= able to notice that several addresses are associated with the same layer 2 = address, but that seems like not what we want to do.

mDN= S seems to just use .arpa.=C2=A0 =C2=A0I don't know how/if that works, = but I definitely don't see how to make it work with the DNS protocol.= =C2=A0 =C2=A0Maybe mDNSResponder caches this information and then returns i= t for 1918 networks and ULA networks, I don't know.



On Thu, Jul 12, 2018 at 11:10 AM, Toke H=C3=B8iland-J=C3=B8rgens= en <= toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.c= om> writes:

>> A few other comments based on a quick read-through:
>>
>> - Since registrations are always done with .local, it is up to the=
>>=C2=A0 =C2=A0registration server to decide which domain(s) the regi= stration ends up
>>=C2=A0 =C2=A0in, right? How is it supposed to do that if servicing = multiple zones?
>>=C2=A0 =C2=A0Just based on source IP?
>>
>
> I think that that's up to the implementation. It could do it based= on
> IP address, or as I suggested in the document it could have a
> whitelist that's maintained by an administrator, based on the key = or
> the name or the service type. As long as it does the same thing every<= br> > time, the details are (I think) immaterial. However, this is worth
> thinking about=E2=80=94if you can come up with something that doesn= 9;t work, we
> should document it.

Right. I *think* that will work; but will probably have to try it ou= t to
be sure :)

>> - The document says that clients must generate their own reverse P= TR
>>=C2=A0 =C2=A0records. Should the server be able to do that on the c= lients behalf?
>>=C2=A0 =C2=A0It may be a matter of policy which ranges have reverse= domain
>>=C2=A0 =C2=A0delegations...
>>
>
> Interesting. I did it this way because I don't want to get into th= e
> "PTR is bad, get rid of it, no it's good, I want it" arg= ument. :)

I'm fine with not having that argument; just want to make sure t= he
standard doesn't disallow it (auto-adding). See below.

> - Related to the above, is it permitted for the registration server to=
>>=C2=A0 =C2=A0modify the records submitted by clients before putting= them into
>>=C2=A0 =C2=A0DNS? For example, to add PTR records, or to remove a s= ubset of the
>>=C2=A0 =C2=A0records etc? The alternative to modifying would be to = reject the whole
>>=C2=A0 =C2=A0registration if a subset is not admissible. If the ser= ver *is* allowed
>>=C2=A0 =C2=A0to modify things, should it communicate back to the cl= ient what it
>>=C2=A0 =C2=A0really did?
>>
>
> Can you think of a scenario where it makes sense to do this? The
> reason that this might not be permissible is simply that I can't t= hink
> of a record other than the PTR record that could be omitted without > making things fail.

What I implemented is that the client will add AAAA records for all<= br> addresses assigned to the interface; and the registration server will
filter out the ones it doesn't like (mostly making sure site-local
addresses don't end up in global DNS). I think this sort of thing shoul= d
be allowed at the server side (could also be a policy like "we don'= ;t
want printers on this network").

The question is if the client should be notified; my server will tell
the client which records were actually created, and the client won't bother maintaining the ones that weren't. However, this is mostly an optimisation; not sure if it's worth specifying in the spec...

>> - You mention in the text that a network may use a different domai= n than
>>=C2=A0 =C2=A0ip6.arpa for reverse PTRs. How does that work? Won'= ;t clients always
>>=C2=A0 =C2=A0do reverse lookups to ip6.arpa?
>
> Unless they are modified.

Right, that's what I thought.

> The point of that is not to suggest that implementing this is
> REQUIRED, but it could be useful for someone, and hence is not
> FORBIDDEN. If you think the text reads as making this a required
> feature, we should fix that! :)

Hmm, don't think it read like it's required, necessarily; I = was just
confused by it. I consider(ed) the reverse domains a static thing not
likely to change, in which case it seems odd to do the mapping from
.local. Is this what happens in mDNS?

-Toke

--000000000000ca6c540570d12131-- From nobody Thu Jul 12 13:49:48 2018 Return-Path: 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 09B21130F83 for ; Thu, 12 Jul 2018 13:49:46 -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 favgIxuhtz0f for ; Thu, 12 Jul 2018 13:49:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF13712F1AC for ; Thu, 12 Jul 2018 13:49:43 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531428578; bh=zM4yAI3qvgPQnUKPCU8hTRPuSfmUV8bl22/OE672B8o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ne+mHtNy2EixkiYakULTZ5nKFUzWiv+A+pcbFSvNFq2WL+F79tk2VrjPKSiPqj6vo 8zYgRD6Yn0gWk1DIZZ7g9g/yBqnAftdsxtu9kfWPEJL3JdRzkHndPruVIQn8cvKO0c 6wn1550wDOXU7CwmtIDLUUYyL44Rezu8lFXL9Neg9i0ZxklXsJF6cTblfLOy6GMMZn ufI9EkHDt8WvMM5AddqK05FDeTTZ3PDvb3SLisMrGCgV0bogprWpEFQYbbrDiktx9A zkQ4TnAtr6RWZbwh6jHWpNWenJ9r8bkd/e66fsUw8/PO6HRsciXPF82h3LSSZiXeJg E9X8836zizw2A== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> Date: Thu, 12 Jul 2018 22:49:30 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sc8b2n9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 20:49:46 -0000 Ted Lemon writes: > It seems like the client should just keep maintaining whatever records > it maintains. If the server doesn't take some updates, then the client > can just keep trying. Otherwise the client has to somehow model the > state of the server, which seems unnecessary. Yeah, agreed. > As for A and AAAA records, this is an open question: how to handle it. > Is it a problem to allow a client to update arbitrary A and AAAA > records? The restriction of only updating the one that corresponds to > the source address used to send the update is there because we have > some reasonable assurance that the client actually has that address. > We could have some hack where we use the neighbor table to notice that > several addresses are associated with the same layer 2 address, but > that seems like not what we want to do. Why is it a problem that a client registers other addresses for its A(AAA) records? As long as it can't update the addresses of another name it can't spoof that service; if it sets another device's address as it's own name, it is just spoofing itself? It could be a problem for PTRs, of course, but not for A(AAA)? Maybe this could also be something that is left up to the registration server as a matter of policy? An example policy could be "only 1 address per subnet per name" or something... But since a client can just generate an infinite number of new names, I'm not really sure that buys much either... > mDNS seems to just use .arpa. I don't know how/if that works, but I > definitely don't see how to make it work with the DNS protocol. Wait, don't see how to make what work with the DNS protocol? -Toke From nobody Thu Jul 12 14:21:23 2018 Return-Path: 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 428F5131192 for ; Thu, 12 Jul 2018 14:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 EDNrOHGPUfSK for ; Thu, 12 Jul 2018 14:21:18 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 680A8131193 for ; Thu, 12 Jul 2018 14:21:18 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id y10-v6so14696226ioa.10 for ; Thu, 12 Jul 2018 14:21:18 -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=jJHrngFdQenEfFJg/lLo86nGh0rsezfo36BmXy1/hN8=; b=egNzB7w8ZCDGz3hY7CpZV9RZtt/His8/MOrX+PVHl+lekk+YjaFjfUClGzPVPmDtOq ddzHSqb0P/kKGdWmeGmjltp7CvLsjGKG7otOvn9uFX4j+vzLRdYquKn4PZzjLA92XMtd eP7SqoeYxnWqqeg+B067J+lHTmc0F5hazkhUwKZm/OaJj9MVr38tqgHg8fhKwF5995D1 aTtqOX93oB6EZOS0OHPkQM9fbgC0lnmxCBLwQysWoyzg0SRqgfBBdgKMq8CslHkc4qwb QUOgI6Vt8yCEj/QLcuBggpoDT8Svdmvc+y+q1PdfyLAXoUkmd28tgZ7jzVWbIMi7rkC8 MJlw== 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=jJHrngFdQenEfFJg/lLo86nGh0rsezfo36BmXy1/hN8=; b=eIS7v+NdbiSM7p+IRhQdyX/xx0GiHNY6CslOBP0wuJ+cSBdCm+s2AeY6f8ZssN0lJp xrZe+q4CP295XKJY6Eg0m5hNEV29aRfeoqI0COZr4upbDJFVM55e6vMUcYPw7SV36Wot Af4T098JkjsECioVvxsqwHcuuUQUcH5ObTMAdamqp0ywz/RGQTceM1KGtPa0mHaixlZY faCdLEwnrL2OxWTbbzwPQ9TwAmQ5wtmG2RXfQpFP06EkrDgAPEDdlczychnSRCllAfcw dDEiaYUpoIIOAKCZ34Fn/HF0AAwgAGK0D7D3UIHknpW8cX4JJKmgA9eg0eat739YxAoA CGfQ== X-Gm-Message-State: AOUpUlGuyRbnVMwyF0SxMgiIEtyZDdDmsJ7O/iDDcQyDBCKjz7hRFjTs s5jSsW/z7j1U1jKEmd/e7IXJLvBlRiPIWquZVv+4jQ== X-Google-Smtp-Source: AAOMgpd4zmTuExy6iVJvEBQsYzialubwKoa/oQNfxCfScp1RZdpoRXYKw260L4IlgvJ3NFBBe5Tve2eAr6aaL1Je8iw= X-Received: by 2002:a6b:b387:: with SMTP id c129-v6mr9081665iof.32.1531430477649; Thu, 12 Jul 2018 14:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:20:37 -0700 (PDT) In-Reply-To: <871sc8b2n9.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 17:20:37 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="0000000000009e75340570d3f145" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:21:22 -0000 --0000000000009e75340570d3f145 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The only reason I think it would be a serious problem for a service to register an IP address other than its own is that it could be used as a way to wedge in an attack. What I mean regarding .arpa is that mDNS literally just multicasts updates to x.y.z.q.in-addr.arpa. over mDNS. So it's completely bypassing DNS delegation of authority. This will work just fine as long as the server processing the update is able to be authoritative for the subdomain of in-addr.arpa corresponding to its address space. The real sticky wicket is that you can't update two zones in the same update, but that's not really what you were talking about. IOW, it has to be in-addr.local in the update, but it can be in-addr.arpa in the zone. On Thu, Jul 12, 2018 at 4:49 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > It seems like the client should just keep maintaining whatever records > > it maintains. If the server doesn't take some updates, then the client > > can just keep trying. Otherwise the client has to somehow model the > > state of the server, which seems unnecessary. > > Yeah, agreed. > > > As for A and AAAA records, this is an open question: how to handle it. > > Is it a problem to allow a client to update arbitrary A and AAAA > > records? The restriction of only updating the one that corresponds to > > the source address used to send the update is there because we have > > some reasonable assurance that the client actually has that address. > > We could have some hack where we use the neighbor table to notice that > > several addresses are associated with the same layer 2 address, but > > that seems like not what we want to do. > > Why is it a problem that a client registers other addresses for its > A(AAA) records? As long as it can't update the addresses of another name > it can't spoof that service; if it sets another device's address as it's > own name, it is just spoofing itself? It could be a problem for PTRs, of > course, but not for A(AAA)? > > Maybe this could also be something that is left up to the registration > server as a matter of policy? An example policy could be "only 1 address > per subnet per name" or something... But since a client can just > generate an infinite number of new names, I'm not really sure that buys > much either... > > > mDNS seems to just use .arpa. I don't know how/if that works, but I > > definitely don't see how to make it work with the DNS protocol. > > Wait, don't see how to make what work with the DNS protocol? > > -Toke > --0000000000009e75340570d3f145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The only reason I think it would be a serious problem for = a service to register an IP address other than its own is that it could be = used as a way to wedge in an attack.

What I mean regardi= ng .arpa is that mDNS literally just multicasts updates to x.y.z.q.in-addr.= arpa. over mDNS.=C2=A0 =C2=A0So it's completely bypassing DNS delegatio= n of authority.=C2=A0 =C2=A0This will work just fine as long as the server = processing the update is able to be authoritative for the subdomain of in-a= ddr.arpa corresponding to its address space.=C2=A0 =C2=A0The real sticky wi= cket is that you can't update two zones in the same update, but that= 9;s not really what you were talking about.=C2=A0 =C2=A0IOW, it has to be i= n-addr.local in the update, but it can be in-addr.arpa in the zone.

On Thu, Jul 1= 2, 2018 at 4:49 PM, Toke H=C3=B8iland-J=C3=B8rgensen <= toke@toke.dk> wrote:
Ted Lemon <= mellon@fugue.com> writes:

> It seems like the client should just keep maintaining whatever records=
> it maintains. If the server doesn't take some updates, then the cl= ient
> can just keep trying. Otherwise the client has to somehow model the > state of the server, which seems unnecessary.

Yeah, agreed.

> As for A and AAAA records, this is an open question: how to handle it.=
> Is it a problem to allow a client to update arbitrary A and AAAA
> records? The restriction of only updating the one that corresponds to<= br> > the source address used to send the update is there because we have > some reasonable assurance that the client actually has that address. > We could have some hack where we use the neighbor table to notice that=
> several addresses are associated with the same layer 2 address, but > that seems like not what we want to do.

Why is it a problem that a client registers other addresses for its<= br> A(AAA) records? As long as it can't update the addresses of another nam= e
it can't spoof that service; if it sets another device's address as= it's
own name, it is just spoofing itself? It could be a problem for PTRs, of course, but not for A(AAA)?

Maybe this could also be something that is left up to the registration
server as a matter of policy? An example policy could be "only 1 addre= ss
per subnet per name" or something... But since a client can just
generate an infinite number of new names, I'm not really sure that buys=
much either...

> mDNS seems to just use .arpa. I don't know how/if that works, but = I
> definitely don't see how to make it work with the DNS protocol.
Wait, don't see how to make what work with the DNS protocol?

-Toke

--0000000000009e75340570d3f145-- From nobody Thu Jul 12 14:27:49 2018 Return-Path: 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 64726131192 for ; Thu, 12 Jul 2018 14:27:47 -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 zNfc62MYM6Ur for ; Thu, 12 Jul 2018 14:27:45 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709B813118E for ; Thu, 12 Jul 2018 14:27:45 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531430862; bh=UWM350jembLn3aJV4Fh5d8TbpLtiCFMBsWCJUMMaoJQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=zNnmVzmnq03f0GxerZ6DEi/ETZbkYi4pO3WUuUYLb17giwNGFNaIbtXzF26E/Ge9H snbEuRLg8JhLurrAoD1uDAIaVJIFxANUXsU0+fEa29mXnEkEsRpiYaSDWDfCz1a7nQ 47WDpyM9G+/KacDhlsCL01l8IqLjjIQqX0yEgZEe9VC17GgXGK3a2EXJC1uHVu+HNx sz04JBs/gYXK68kt/PdYIufbbZPBzbNpWGsY0kXvcRckKJQS8tg5lHMyxJznyKSE3T J7BLPW681Wv9tyrwVPJhTeJQT4HBdmaWCerV6cImL0/X5zhTZPB/qcE5pv5h6oPnfo a4Rpeuv4ze59A== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> Date: Thu, 12 Jul 2018 23:27:41 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvp49mb6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:27:47 -0000 Ted Lemon writes: > The only reason I think it would be a serious problem for a service to > register an IP address other than its own is that it could be used as > a way to wedge in an attack. Right. But if we want to protect against that we'd need to only allow registrations for the IP we are talking to; which means separate registrations for IPv4 and IPv6. And for v4 it would probably mean a requirement for on-link presence, since anything that is not on-link is likely to have at least one layer of NAT in-between... > The real sticky wicket is that you can't update two zones in the same > update, but that's not really what you were talking about. Ah, right, then it makes sense. I may have been ignoring this part of the spec in my implementation ;) -Toke From nobody Thu Jul 12 14:33:14 2018 Return-Path: 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 6C0EF13119A for ; Thu, 12 Jul 2018 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 F8dYg3RjkjHV for ; Thu, 12 Jul 2018 14:33:10 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9D006130E18 for ; Thu, 12 Jul 2018 14:33:10 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l14-v6so19601374iob.7 for ; Thu, 12 Jul 2018 14:33:10 -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=wJSGz8Q3w/rimRdcUFnzpUFhkLsOQF4e+h3OeEUFO9I=; b=uwc821Fo5k+TXRtxrEZCjhT5tj2cUPcsBKhBcz8Wm8H780bAfsCBMSdGVyub7FAc1e VSsFIjaVX7DSKgLtxK5BxMlp5tNEC3ufgqImJmZ/JgHN2OzFLgtdQmtMZajxOdQNMOGU 45kqKiJDvSzabz6Iu04JpqzljruFKhwIbDR/hOjAYDNQmXSXU/Xi99ZmvKoALuCcLuD5 OGDMhdqayFpTMOMR5rai8X9ervdWftQlT5Yn6XGAlAD9Z6rFLZOXphb9bcXv71nWIpgx jtDHThZOf3usXQ7KGK9U1iNE6vLmYqcrGtW0DLBXxABTarmHbKqi3legJZW6jIpfTFif AUYg== 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=wJSGz8Q3w/rimRdcUFnzpUFhkLsOQF4e+h3OeEUFO9I=; b=ZlWYd34oFOqsxO7KTH3EYmrGdlP2biFqyMIUwqKJXn5aDvuTHWVVY6dIF3et4E1FuL Xb0M9QCvJnAi1IHYtwetg+1wzEV63ZUVX+NZ6tUC28rTsQ1O+Nyi4vZt9wHsUgIgWl2E qQI4M/e9M5pYE6nTUlyqnWY3Zlo+luLFozKX3KyfcdaZrOxRy9jKI2b+Ighpmehc0n1o lpplgkLP0rHnU+hGh4oEil49dzvnr5RcBt25qL3YWn1hUfRtOlNoTNZIfqej7VuzHHNv VK5R880x9h98UkC33q0LjSYztdG5L1ktwEyiwGHfvQjJ7kiNrVsw9KXed2houe/eEB65 0xDg== X-Gm-Message-State: AOUpUlEfqUOiizbV5zHfdfNDVggHjAss8atG+HGARhSvgp2NA0oXjg21 TA989QzTQ391Rk8n/SIIciq1aaLLWuvNBi6OnNvHiA== X-Google-Smtp-Source: AAOMgpde8Dwx0qxABDLW7C3J4pbGorFIp6jIu/M/aO1H7KHM0A2F77xRw2kKZe+dDUwh7IPIMXYF5XLbgdCrYztZcPY= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr30342888ioe.85.1531431189987; Thu, 12 Jul 2018 14:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:32:29 -0700 (PDT) In-Reply-To: <87tvp49mb6.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> <87tvp49mb6.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 17:32:29 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="00000000000013de220570d41c53" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:33:12 -0000 --00000000000013de220570d41c53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, this requires separate registrations for IPv4 and IPv6. I think that's okay. What's a bit chancy is that it also means that if you have a ULA and a GUA, you have to pick one, or do two updates. As for NAT, I think we have to assume that the network is not double-natted. If it's a homenet, that will be true. If it's a campus network, that will be true. If it's a bunch of crappy routers plugged together, it's unlikely that service registration will be available anyway, so we don't care. Do you buy that? :) On Thu, Jul 12, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > The only reason I think it would be a serious problem for a service to > > register an IP address other than its own is that it could be used as > > a way to wedge in an attack. > > Right. But if we want to protect against that we'd need to only allow > registrations for the IP we are talking to; which means separate > registrations for IPv4 and IPv6. And for v4 it would probably mean a > requirement for on-link presence, since anything that is not on-link is > likely to have at least one layer of NAT in-between... > > > The real sticky wicket is that you can't update two zones in the same > > update, but that's not really what you were talking about. > > Ah, right, then it makes sense. I may have been ignoring this part of > the spec in my implementation ;) > > -Toke > --00000000000013de220570d41c53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, this requires separate registrations for IPv4 and IPv= 6.=C2=A0 =C2=A0I think that's okay.=C2=A0 =C2=A0What's a bit chancy= is that it also means that if you have a ULA and a GUA, you have to pick o= ne, or do two updates.=C2=A0 =C2=A0As for NAT, I think we have to assume th= at the network is not double-natted.=C2=A0 =C2=A0If it's a homenet, tha= t will be true.=C2=A0 =C2=A0If it's a campus network, that will be true= .=C2=A0 =C2=A0If it's a bunch of crappy routers plugged together, it= 9;s unlikely that service registration will be available anyway, so we don&= #39;t care.=C2=A0 =C2=A0Do you buy that?=C2=A0 =C2=A0:)

On Thu, Jul 12, 2018 at 5:27 PM= , Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

> The only reason I think it would be a serious problem for a service to=
> register an IP address other than its own is that it could be used as<= br> > a way to wedge in an attack.

Right. But if we want to protect against that we'd need to only = allow
registrations for the IP we are talking to; which means separate
registrations for IPv4 and IPv6. And for v4 it would probably mean a
requirement for on-link presence, since anything that is not on-link is
likely to have at least one layer of NAT in-between...

> The real sticky wicket is that you can't update two zones in the s= ame
> update, but that's not really what you were talking about.

Ah, right, then it makes sense. I may have been ignoring this part o= f
the spec in my implementation ;)

-Toke

--00000000000013de220570d41c53-- From nobody Thu Jul 12 14:39:25 2018 Return-Path: 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 DF1FF1311AD for ; Thu, 12 Jul 2018 14:39:22 -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 MUjWUJTQzf-l for ; Thu, 12 Jul 2018 14:39:21 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C691311A7 for ; Thu, 12 Jul 2018 14:39:20 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531431559; bh=zFpDbzoTue+/NdSpLiFMbcH9475ETHBK/rYxqgD3Szs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=coe5yStjoLeT5/AGlTgrCIoU311ph3WncpYxsnh90UBvUAGIQEjbKWYE8CjPUzFu2 2Q5dMCKhHiVjopFhAliuvggOdSfmh6dP1i4H2gqDwXzpvUcpDSlN7fyQxH/HeKSmXy WgXejcJuuOnSw+TCMVxBMgOFETiMbWdL1OyIuf2TKPobUtB8KizX8B2FvromIfmIrY PuSNcARxIL7dPAE2cAGSh0Rm2s9V5O/YPEl75WdmJzKuYqhiuEsUCCh8OsUJgTDWb3 pRxVO7etLDtxxQcWswJihsVL7Fr74syDESNLylXOU024grpAEJmJJw39m0Lk8tBWEb LceV0HEJ04XtQ== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> <87tvp49mb6.fsf@toke.dk> Date: Thu, 12 Jul 2018 23:39:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pnzs9lrt.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:39:23 -0000 Ted Lemon writes: > Yes, this requires separate registrations for IPv4 and IPv6. I think > that's okay. What's a bit chancy is that it also means that if you > have a ULA and a GUA, you have to pick one, or do two updates. As for > NAT, I think we have to assume that the network is not double-natted. > If it's a homenet, that will be true. If it's a campus network, that > will be true. If it's a bunch of crappy routers plugged together, it's > unlikely that service registration will be available anyway, so we > don't care. Do you buy that? :) Heh. For now, probably; by the time this becomes a standard, who knows? (but surely there will be no more IPv4 by then, right? ;)) My concern is that requiring client address visibility breaks my deployment use case, where the registration server lives in the cloud... Or rather, I could probably live without v4, but I wouldn't be surprised if someone else got the same idea (DNSSD as a service? One could potentially run a dyndns type service using the same mechanism...). -Toke From nobody Thu Jul 12 14:45:16 2018 Return-Path: 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 D87751311B1 for ; Thu, 12 Jul 2018 14:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 plXreazTZdPV for ; Thu, 12 Jul 2018 14:45:11 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 512911277BB for ; Thu, 12 Jul 2018 14:45:11 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id w16-v6so8937562ita.0 for ; Thu, 12 Jul 2018 14:45:11 -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=QiWCk1Zbuk5fVnL8bKrCvMJ3YfQKJpd1RICcmoItrwQ=; b=iQxQibBReDbIDu47/GTrCPutruZzC0EX9O/lvhIYJtgVrLHGWvet7P2KSfF+Kosr1q htw9wSxnJR2V6m/VNW0E8hP+pZXP94ulrApAYVxJBULJ5OrkqGHsd6xpkKYGvUQDQDKF +vbNaVzH0zap1x6QdKQfkxyP+Fb8BlcG2ZvyoECJARBXe0gh96Gg3yX5UlWa5EtUszFn Lhk2vWXfgkGLULnzX0qQWHd/lBXezPX3L0so+s4W1bUSubYhiH1pdZqT7uDhpYsrmkWR RL9oijcBlghvE2LkTmEQcLiy6TeD9PDDr9kx/HpVm1WkhV6Fg0bygWymReGuBhldkUCW Mr4g== 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=QiWCk1Zbuk5fVnL8bKrCvMJ3YfQKJpd1RICcmoItrwQ=; b=g99jI7w0Gqa9yJHPyOyXccBzAh84TfWeLdCLJ5fnRcq8hNbz7ZxsEYWDHUD1jCX5vc B1La/7pXuk4ZY3M5g1Cw3Y+z/t7l8k3IXjrMUcOlwCjonjbE4S5Y8xGx579bQXWzQp1y 5XIQc5Vo2G2RjsjB0ottrKjD73PV4zsntMvvPonEvrOj66hrHfAvBc6kqgiS+914wC4v qfFbuoQHtqmfKEeKia+9m5uCOWfxbXG8VTEGWNvVf+ALqw1byUv9uD14J5HSr6EWpssG Hs4DMDoeIM3Q0Mq2FfSuivCA0XfxqfBnKU84SErxzf8AVwB3t9UtJ4o+errcl6QPzy1E hTsA== X-Gm-Message-State: AOUpUlG87TeATJwDETMql8Zn3yeDYZ/zywUgf9EMCoZ1LSmXroTWmqAg LFniTsaVG3QjKd4vpqZeEKPccardx1iF/IU2RrBG+w== X-Google-Smtp-Source: AAOMgpdSJoUBIS7FHVSzyxPhGqCVHiVc8oDP0r256uWYVV5CPnsN0MkcWYfOTSdQFue09aCyb30h+IdQaEl5FE2W/lg= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr2855930itg.82.1531431910507; Thu, 12 Jul 2018 14:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:44:29 -0700 (PDT) In-Reply-To: <87pnzs9lrt.fsf@toke.dk> References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> <87tvp49mb6.fsf@toke.dk> <87pnzs9lrt.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 17:44:29 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="000000000000062e8e0570d44711" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:45:14 -0000 --000000000000062e8e0570d44711 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm. For the cloud case, with NAT, that seems kind of problematic anyway, because now you have A records in the public DNS pointing at RFC1918 addresses. The right way to handle this is with PCP and an SRV record pointing at the NAT router's public address and using the PCP-assigned port. I didn't document this because I think it's kind of an extra-cost option, but that's how it would have to work. On Thu, Jul 12, 2018 at 5:39 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > Yes, this requires separate registrations for IPv4 and IPv6. I think > > that's okay. What's a bit chancy is that it also means that if you > > have a ULA and a GUA, you have to pick one, or do two updates. As for > > NAT, I think we have to assume that the network is not double-natted. > > If it's a homenet, that will be true. If it's a campus network, that > > will be true. If it's a bunch of crappy routers plugged together, it's > > unlikely that service registration will be available anyway, so we > > don't care. Do you buy that? :) > > Heh. For now, probably; by the time this becomes a standard, who knows? > (but surely there will be no more IPv4 by then, right? ;)) > > My concern is that requiring client address visibility breaks my > deployment use case, where the registration server lives in the cloud... > Or rather, I could probably live without v4, but I wouldn't be surprised > if someone else got the same idea (DNSSD as a service? One could > potentially run a dyndns type service using the same mechanism...). > > -Toke > --000000000000062e8e0570d44711 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm.=C2=A0 =C2=A0For the cloud case, with NAT, that seems k= ind of problematic anyway, because now you have A records in the public DNS= pointing at RFC1918 addresses.=C2=A0 =C2=A0The right way to handle this is= with PCP and an SRV record pointing at the NAT router's public address= and using the PCP-assigned port.=C2=A0 =C2=A0I didn't document this be= cause I think it's kind of an extra-cost option, but that's how it = would have to work.

On Thu, Jul 12, 2018 at 5:39 PM, Toke H=C3=B8iland-J=C3=B8rgensen <= span dir=3D"ltr"><toke= @toke.dk> wrote:
Ted Lemon <mellon@fugue.com= > writes:

> Yes, this requires separate registrations for IPv4 and IPv6. I think > that's okay. What's a bit chancy is that it also means that if= you
> have a ULA and a GUA, you have to pick one, or do two updates. As for<= br> > NAT, I think we have to assume that the network is not double-natted.<= br> > If it's a homenet, that will be true. If it's a campus network= , that
> will be true. If it's a bunch of crappy routers plugged together, = it's
> unlikely that service registration will be available anyway, so we
> don't care. Do you buy that? :)

Heh. For now, probably; by the time this becomes a standard, who kno= ws?
(but surely there will be no more IPv4 by then, right? ;))

My concern is that requiring client address visibility breaks my
deployment use case, where the registration server lives in the cloud... Or rather, I could probably live without v4, but I wouldn't be surprise= d
if someone else got the same idea (DNSSD as a service? One could
potentially run a dyndns type service using the same mechanism...).

-Toke

--000000000000062e8e0570d44711-- From nobody Thu Jul 12 14:47:50 2018 Return-Path: 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 25A891311B3 for ; Thu, 12 Jul 2018 14:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 wqyxU3UGP_B3 for ; Thu, 12 Jul 2018 14:47:46 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 4AB7F1311A1 for ; Thu, 12 Jul 2018 14:47:46 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id l7-v6so29601555ioj.1 for ; Thu, 12 Jul 2018 14:47:46 -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=VhfukJfPx9hr/0l4VyUhjmTBXoYPBg/hQF+fPS0UNgQ=; b=raP3RgWMRyX6aiQDXknww4Bclx5szQ5uYiXfI0u9t8mEBllKnDqk2uXuy9rWXpm/ny 7oQcC4tc9cBOw9zfYOoXde8WD8+YOFTMQ5cpKSXDimqpbMQHtED7wqTQ61dUU40GP5+3 lPlAkbjiS0L+TL6Bbler4eJYcVu3x2UgtjRxmaR1GP1OZCU5Jtm32SvnzMDvBNTjxPL0 vIO9+XEg9rlfTAnQUVc2fBuXINWHHxKPyhXb7mhBTDMp+PSvAQchs6UAyjMxIjjeQHMm Shp9IzfUjPwDOlueS6EZ9KtaFxoyccIAI1XftCgi+gBehxwh75OE+0neCVKYdQa7Z4op 3DYw== 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=VhfukJfPx9hr/0l4VyUhjmTBXoYPBg/hQF+fPS0UNgQ=; b=anTNdUfFsMUXE581RG6hILjKY9Z77aylgoxuxDp3kCDsJxwTHjUsdJ/GdDUakCILiR Tb95OXIWX1J6kDMq0FKBJ9DBjqtzd5npPyTc7/Goy+cA3WwkDoXtXRSRd4ewUA+yIEdD voI75+gToYMqH3B4YNKoYWSLV3YD095DaQKsuP6NmoZIFmUZ10UDq4+4dAAS6mp3pNga avJ06ObQgHfXGQuBRUeIvz6us6MI7btE5ID+JPKT/bUD5qtVCa5r/e8XCZPGT8RbR9ie 75KOHqsbfXh18SlUPa2ly8d9mOnFxbP/z4FFIheA6U0jAmpCljS1sbt9aadCj52lgPs1 Xbkw== X-Gm-Message-State: APt69E2po2IgwtsYdHYonwFgWHiT7Sqi1tUStibB5lAyVbCCc54+ugHM 24dmuvYVAiza4M+F6p+xG8TWKEe0/WxeuYgCEjviMw== X-Google-Smtp-Source: AAOMgpdnKt7J/fx9x+QLN9pyT9GcacVp4oznq1Fe5iekcU/qtBFW76eeqEODoaVjSpMCpBN9uh5AGLLmyIrLg6cfa0c= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr28851129ioc.45.1531432065663; Thu, 12 Jul 2018 14:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:47:05 -0700 (PDT) In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> <87tvp49mb6.fsf@toke.dk> <87pnzs9lrt.fsf@toke.dk> From: Ted Lemon Date: Thu, 12 Jul 2018 17:47:05 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: David Schinazi , dnssd Content-Type: multipart/alternative; boundary="000000000000459c930570d4502a" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 21:47:49 -0000 --000000000000459c930570d4502a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Er, slight clarification, if you want to do Registration Protocol the way you're describing, and you don't care about the RFC1918 issue, then you'd need the update to go to your edge router, which would validate the Registration and then turn it into one or more regular RFC2136-style updates. That implementation could be relatively stateless (only state in memory, only until the transaction is done). On Thu, Jul 12, 2018 at 5:44 PM, Ted Lemon wrote: > Hm. For the cloud case, with NAT, that seems kind of problematic anyway= , > because now you have A records in the public DNS pointing at RFC1918 > addresses. The right way to handle this is with PCP and an SRV record > pointing at the NAT router's public address and using the PCP-assigned > port. I didn't document this because I think it's kind of an extra-cost > option, but that's how it would have to work. > > On Thu, Jul 12, 2018 at 5:39 PM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > >> Ted Lemon writes: >> >> > Yes, this requires separate registrations for IPv4 and IPv6. I think >> > that's okay. What's a bit chancy is that it also means that if you >> > have a ULA and a GUA, you have to pick one, or do two updates. As for >> > NAT, I think we have to assume that the network is not double-natted. >> > If it's a homenet, that will be true. If it's a campus network, that >> > will be true. If it's a bunch of crappy routers plugged together, it's >> > unlikely that service registration will be available anyway, so we >> > don't care. Do you buy that? :) >> >> Heh. For now, probably; by the time this becomes a standard, who knows? >> (but surely there will be no more IPv4 by then, right? ;)) >> >> My concern is that requiring client address visibility breaks my >> deployment use case, where the registration server lives in the cloud... >> Or rather, I could probably live without v4, but I wouldn't be surprised >> if someone else got the same idea (DNSSD as a service? One could >> potentially run a dyndns type service using the same mechanism...). >> >> -Toke >> > > --000000000000459c930570d4502a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Er, slight clarification, if you want to do Registration P= rotocol the way you're describing, and you don't care about the RFC= 1918 issue, then you'd need the update to go to your edge router, which= would validate the Registration and then turn it into one or more regular = RFC2136-style updates.=C2=A0 =C2=A0That implementation could be relatively = stateless (only state in memory, only until the transaction is done).
=

On Thu, Jul 12, 2= 018 at 5:44 PM, Ted Lemon <mellon@fugue.com> wrote:
Hm.=C2=A0 =C2=A0For the cloud cas= e, with NAT, that seems kind of problematic anyway, because now you have A = records in the public DNS pointing at RFC1918 addresses.=C2=A0 =C2=A0The ri= ght way to handle this is with PCP and an SRV record pointing at the NAT ro= uter's public address and using the PCP-assigned port.=C2=A0 =C2=A0I di= dn't document this because I think it's kind of an extra-cost optio= n, but that's how it would have to work.

On= Thu, Jul 12, 2018 at 5:39 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
Ted Lemon &l= t;mellon@fugue.com> writes:

> Yes, this requires separate registrations for IPv4 and IPv6. I think > that's okay. What's a bit chancy is that it also means that if= you
> have a ULA and a GUA, you have to pick one, or do two updates. As for<= br> > NAT, I think we have to assume that the network is not double-natted.<= br> > If it's a homenet, that will be true. If it's a campus network= , that
> will be true. If it's a bunch of crappy routers plugged together, = it's
> unlikely that service registration will be available anyway, so we
> don't care. Do you buy that? :)

Heh. For now, probably; by the time this becomes a standard, who kno= ws?
(but surely there will be no more IPv4 by then, right? ;))

My concern is that requiring client address visibility breaks my
deployment use case, where the registration server lives in the cloud... Or rather, I could probably live without v4, but I wouldn't be surprise= d
if someone else got the same idea (DNSSD as a service? One could
potentially run a dyndns type service using the same mechanism...).

-Toke


--000000000000459c930570d4502a-- From nobody Thu Jul 12 15:50:19 2018 Return-Path: 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 37CEE13120A for ; Thu, 12 Jul 2018 15:50:17 -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 VWlmnS0INSrx for ; Thu, 12 Jul 2018 15:50:15 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523431311F6 for ; Thu, 12 Jul 2018 15:50:15 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531435813; bh=5gzlBpDFq+Dw/Y40ypYvmwGw/0rhv4Dl9yEtKho47C0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=p0p/wcWbNrTvcTPWAgK+20pjjjvUfGPwNjuvp1FgQzj5XX0HFQWNN1pDK0Yls4/ai bB9ydQfwcP9hbP94Foazyqua7xUbvLJEvYVhkGjf4rF1unM4CSJDtyBj3aHoE1yw5y Aj6mhYalgJSFkC2OsFU/FCKI0S4iqmcEfuGmXz2rQaWP+5FwI2e7+xpLviWdDLMFsW tx9ogdESACNM3u8K1yPjS/1qwZRGG/OnNcTe/833i1UamgmHvli5RFxXyYU+JcF5f+ 007pDULxPF/c8Rdp1an69RzBH06OUl3JtRQn5zH1LJnv4eep2iqV2rlL9zy3zUei/Z UzlFzxCet1Tlw== To: Ted Lemon Cc: David Schinazi , dnssd In-Reply-To: References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <87lgare65v.fsf@toke.dk> <87in5td3ar.fsf@toke.dk> <87r2kbcl3h.fsf@toke.dk> <87fu0obuua.fsf@toke.dk> <874lh4bicx.fsf@toke.dk> <871sc8b2n9.fsf@toke.dk> <87tvp49mb6.fsf@toke.dk> <87pnzs9lrt.fsf@toke.dk> Date: Fri, 13 Jul 2018 00:50:09 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87muuw9ihq.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:50:18 -0000 Ted Lemon writes: > Hm. For the cloud case, with NAT, that seems kind of problematic > anyway, because now you have A records in the public DNS pointing at > RFC1918 addresses. Unless the registration server knows how to talk to the gateway resolver and install the RFC1918 addresses as local only (and put the global v6 addresses into global DNS). That's what I'm doing now; but having the registration server in the cloud means I can use a standard unbound instance on the gateway; and also the gateway doesn't need to have access to update the global DNS... -Toke From nobody Sun Jul 15 13:40:27 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A9B130DDC; Sun, 15 Jul 2018 13:40:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <153168722009.21892.53452792031975579@ietfa.amsl.com> Date: Sun, 15 Jul 2018 13:40:20 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-sctl-service-registration-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.27 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: Sun, 15 Jul 2018 20:40:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Stuart Cheshire Ted Lemon Filename : draft-sctl-service-registration-02.txt Pages : 16 Date : 2018-07-15 Abstract: The DNS-SD Service Registration Protocol uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This eliminates the dependency on Multicast DNS as the foundation layer, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sctl-service-registration/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-sctl-service-registration-02 https://datatracker.ietf.org/doc/html/draft-sctl-service-registration-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-sctl-service-registration-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 15 13:43:23 2018 Return-Path: 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 56074130E41 for ; Sun, 15 Jul 2018 13:43:21 -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 vQUYEx47FVmN for ; Sun, 15 Jul 2018 13:43:18 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 74DB3130DDC for ; Sun, 15 Jul 2018 13:43:18 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id v71-v6so18351353itb.3 for ; Sun, 15 Jul 2018 13:43:18 -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; bh=vjKIjWyDLbmi2k5si3xvvBx9fhwQF6lXeeFdvciFhdg=; b=peaUkaw6YQrU2OxhjR53d/4Bh2GdMvVbBxlhWf2MjXUJV/sOxkl8TRImGVHzepbxqA KAt8gXbyiO8LRMpY5qn2HKuCruBfm2yuE0JwJukXcAnxGY8tmefh6/RgTxVejLlUDayM fagr5N+UnFPsT9xR3i5ISnMfEiYVqMZcoexllM8fVTLGM/KTvH3l50fGY9i5q3j2xVkk cc6QrGuyxA0DSGnBHqGBehDwOHcipmJP6P+G6j+AG6hDAh6nkYtvbYhuR18KrFgHSM/r Hc02RIyLI/rFVZeMRXrPvHET/qHzahQaQwZqEd87VnHB8eC+yRYxjaztqZiHA6JgHYms RV0Q== 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; bh=vjKIjWyDLbmi2k5si3xvvBx9fhwQF6lXeeFdvciFhdg=; b=s9bXG73ORXM9Eqk5b8hKu+KzM25+EQvMZEHZdjKcPJoIgxI0qdeIXWGU2T1/3iSfon 9aW9vtG8PHBmYj641De2y3ES0QxUuWkExIPYhtqeAThF9pOcbV+UfoaY1IhnE4GnCf0d dh/ihUZJ/apPHGvF1VdQuNT5BkXLjaT5obAajV1sGn2d3KXrgGMTn4XVQjkWfiww6c2u td0ZEdcULGPSCigYSBCqaoE8P9bgI1PXCTSZB48Tcx2oO+LTi9BvQG2ku4LDLhxualJl 7nd9lf3THTWOuhHH9r6Zeazj78Wwd4EF27ryMA5RjZE9ocvrHHYhzqAVCX6sgCtKTuxf lX0Q== X-Gm-Message-State: AOUpUlECBArD7nX2CLZ9vO6Tgczy+WALWYlAWhaDRAxLDuK0Q5STKzj3 iqgzfjXcPuwLBsPC8259uwjwfaFFQhNAQrg9keC1UQ== X-Google-Smtp-Source: AAOMgpcWt5SHBhKvLfq9/2PhxBjaS7wb3UkGwNEB3reR4yCTV/G+1Oz2HGvwHfzqfmjMU+SoTbGpGyqIMy7cichQBIQ= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr11152327itg.82.1531687397536; Sun, 15 Jul 2018 13:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 13:42:37 -0700 (PDT) In-Reply-To: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Sun, 15 Jul 2018 16:42:37 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="0000000000003cd61805710fc3ae" Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 20:43:21 -0000 --0000000000003cd61805710fc3ae Content-Type: text/plain; charset="UTF-8" I just submitted an updated version of the service registration document. If you were planning to read this prior to the meeting and haven't read it yet, you should definitely read the new version. I think it's more understandable than the old version, but more importantly, it's also more correct. This version contains significant updates from the version that Toke reviewed last week. Things move fast at the IETF... ---------- Forwarded message ---------- From: Date: Sun, Jul 15, 2018 at 4:40 PM Subject: New Version Notification for draft-sctl-service-registration-02.txt To: Stuart Cheshire , Ted Lemon A new version of I-D, draft-sctl-service-registration-02.txt has been successfully submitted by Ted Lemon and posted to the IETF repository. Name: draft-sctl-service-registration Revision: 02 Title: Service Registration Protocol for DNS-Based Service Discovery Document date: 2018-07-14 Group: dnssd Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-sctl-service- registration-02.txt Status: https://datatracker.ietf.org/doc/draft-sctl-service- registration/ Htmlized: https://tools.ietf.org/html/draft-sctl-service- registration-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-sctl-service- registration Diff: https://www.ietf.org/rfcdiff?url2=draft-sctl-service- registration-02 Abstract: The DNS-SD Service Registration Protocol uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This eliminates the dependency on Multicast DNS as the foundation layer, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000003cd61805710fc3ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just submitted an updated version of the service registr= ation document.=C2=A0 =C2=A0If you were planning to read this prior to the = meeting and haven't read it yet, you should definitely read the new ver= sion.=C2=A0 =C2=A0I think it's more understandable than the old version= , but more importantly, it's also more correct.

This= version contains significant updates from the version that Toke reviewed l= ast week.=C2=A0 =C2=A0Things move fast at the IETF...

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, J= ul 15, 2018 at 4:40 PM
Subject: New Version Notification for draft-sctl-= service-registration-02.txt
To: Stuart Cheshire <cheshire@apple.com>, Ted Lemon <mellon@fugue.com>



A new version of I-D, draft-sctl-service-registration-02.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sctl-service-regis= tration
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Registration Protocol for = DNS-Based Service Discovery
Document date:=C2=A0 2018-07-14
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dnssd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-sctl-s= ervice-registration-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sctl-service-registr= ation/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-sctl-service-registration-02<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sctl-service-reg= istration
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sctl-service= -registration-02

Abstract:
=C2=A0 =C2=A0The DNS-SD Service Registration Protocol uses the standard DNS= Update
=C2=A0 =C2=A0mechanism to enable DNS-Based Service Discovery using only uni= cast
=C2=A0 =C2=A0packets.=C2=A0 This eliminates the dependency on Multicast DNS= as the
=C2=A0 =C2=A0foundation layer, which greatly improves scalability and impro= ves
=C2=A0 =C2=A0performance on networks where multicast service is not an opti= mal
=C2=A0 =C2=A0choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) network= s.
=C2=A0 =C2=A0DNS-SD Service registration uses public keys and SIG(0) to all= ow
=C2=A0 =C2=A0services to defend their registrations against attack.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--0000000000003cd61805710fc3ae-- From nobody Sun Jul 15 18:55:24 2018 Return-Path: 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 91219130F2A for ; Sun, 15 Jul 2018 18:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SiV4RwYjs_qY for ; Sun, 15 Jul 2018 18:55:21 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCCE1292AD for ; Sun, 15 Jul 2018 18:55:21 -0700 (PDT) Received: from [192.168.1.12] (modemcable091.29-131-66.mc.videotron.ca [66.131.29.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 404096DF; Sun, 15 Jul 2018 21:53:40 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: Date: Sun, 15 Jul 2018 21:55:18 -0400 Cc: dnssd Content-Transfer-Encoding: quoted-printable Message-Id: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 01:55:24 -0000 > On Jul 15, 2018, at 4:42 PM, Ted Lemon wrote: >=20 > I just submitted an updated version of the service registration = document. If you were planning to read this prior to the meeting and = haven't read it yet, you should definitely read the new version. I = think it's more understandable than the old version, but more = importantly, it's also more correct. >=20 > This version contains significant updates from the version that Toke = reviewed last week. Things move fast at the IETF... >=20 Some quick feedback on the latest version: 1. You reference mDNS but don=E2=80=99t define it as multicast DNS or = reference RFC 6762. 2. Section 2, second paragraph, you mention registering with the default = registration domain ("dr._dns-sd._udp=E2=80=9D). a. You could add Section 11 to the RFC 6763 reference. b. You don=E2=80=99t specify if you should use the .local domain = or another domain. If it=E2=80=99s another domain, how do you find that = domain? c. Why do you recommend always using the default registration = domain? Couldn=E2=80=99t you get the list of registration domains = ("r._dns-sd._udp=E2=80=9D) and pick one of those? 3. It=E2=80=99s not clear to me from the document about the TTL values. = The life of the registration is handled by the Update Lease Time and the = Instance Lease Time. Therefore, I think the document is saying (after = talking to Stuart) that the TTL in the registration is the one the = client wants the server to use in responses. But the server is keeping = the registration for longer than the TTL based on the EDNS(0) Update = Lease Option values. So does the server start the TTL countdown on the first response and = then subsequent responses use the decrementing TTL until it times out = and then the server resets it to the TTL it received in the register on = the next response? This is confusing to me even after talking to Stuart = so I=E2=80=9Dm probably just missing something. 4. Section 3 (security considerations) You limit the scope of this to within an administrative domain limiting = it=E2=80=99s applicability but nowhere else in the document do you = convey this. For most of the document, the reader may assume that = registrations can be done from anywhere, may wonder why they aren=E2=80=99= t encrypted, and then only see in the security section that this is = really made for IoT devices and in the home. I think the name of the protocol should reflect this limited scope = instead of using a generic name like Service Registration Protocol since = it isn=E2=80=99t designed to be used as a generic unicast service = registration protocol. Maybe something like Local Service Registration = Protocol or Site Service Registration Protocol or Constrained Service = Registration Protocol or something better than I can=E2=80=99t think of = right now, Thanks, Tom From nobody Sun Jul 15 19:19:36 2018 Return-Path: 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 34696130E40 for ; Sun, 15 Jul 2018 19:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 C79z9cgDzqsb for ; Sun, 15 Jul 2018 19:19:32 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 491A8130DEF for ; Sun, 15 Jul 2018 19:19:32 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 72-v6so2558853itw.3 for ; Sun, 15 Jul 2018 19:19:32 -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=/6fMlvdUt8HkTv/OoK7jT77CjjY0uDnz2klj+O1+Mks=; b=f4TVC9NdJqXmz2OeB5zqHVBOy5l/PSBoOmdSjAki7qEkmw2ZmSMKzfOOYQ9dlRR8Ue 5CrpeyvorSb+Qbxys+usKtdUw4yImyWKvrF308DIiwaH8N4Dx6gsnoL/W+HnbpSJmjTl ZUjIzIOC7TioLPMh4iLd8t1wLX1t1KdPw6iAiQl/TXhfGZS4NztcnFU9NAUtZoXSAP9I UTM890hRy6Dxp4ne+7LK1S3XeYywQVhCS5mp7CjzGwkp3wCMLoAqfBlHvCG3khIJmUyp AI2eGWuihKjKFw0I1ro6KA/sgKAV/CbRZ4MrDAxptqRx62Opg+Znx0GgFg12nQePLyxe 61NA== 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=/6fMlvdUt8HkTv/OoK7jT77CjjY0uDnz2klj+O1+Mks=; b=CPDzI0JaKHc5WRuDMJRaSmloqrZQoCbWn+/XwY/xQBUnsX9KvRgvEnprTUPR18pIS9 808yZipcSd1bExMSrzIMQ2GeBvdL+YIgtkgz5t+/UgJlOhPTY2EAOS8GOpMf1sLAwNfp R7lOkrB8hHlh6JvNVtO/7jYVoVYib2VZk/6XibEKPu7aFx1faewpIU1VQGv0NvZdaoVZ BtQGQ4SAXJntyjNiMQIpP+qBRP/Gh77MZrZluIYG1bWR5bR19Nadb1wtRNw+OkN5xc3y PsAP9PQ/xCbWonp4QEAG1eLj/0bz5lh+T659XRLvin0QMHwhKMqhWA+/TDQ/R6vTQJBB CxVQ== X-Gm-Message-State: AOUpUlFSqDu2p+btSQmtlABc0/1nM8C84NMVEvcZpDOhAGq6tPUcucou n+40slFHBwHoYhwfJSfnbpTLYsPC2Le5wR0H4Krv6g== X-Google-Smtp-Source: AAOMgpcz0wWOeRIMtMfLT2WSsj1KPOxAsYCn2AeayB/sZuxAee9d+gFX2Q4fvzU4gn+gtO6lB8Hc3c1xasosnuYHnvQ= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr11663342itg.82.1531707571396; Sun, 15 Jul 2018 19:19:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 19:18:50 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Sun, 15 Jul 2018 22:18:50 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000b17b1005711475fe" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 02:19:35 -0000 --000000000000b17b1005711475fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 15, 2018 at 9:55 PM, Tom Pusateri wrote: > Some quick feedback on the latest version: > Thanks! :) > 1. You reference mDNS but don=E2=80=99t define it as multicast DNS or ref= erence > RFC 6762. > We do reference RFC6762 in the introduction, but you're right that we don't introduce the term properly. > 2. Section 2, second paragraph, you mention registering with the default > registration domain ("dr._dns-sd._udp=E2=80=9D). > > a. You could add Section 11 to the RFC 6763 reference. > Good point, thanks. > b. You don=E2=80=99t specify if you should use the .local domain = or > another domain. If it=E2=80=99s another domain, how do you find that doma= in? > We specify that you should discover the default registration domain and use that. It sounds like this wasn't sufficiently clear, though. :) > c. Why do you recommend always using the default registration > domain? Couldn=E2=80=99t you get the list of registration domains > ("r._dns-sd._udp=E2=80=9D) and pick one of those? > This is an automatic protocol, so that would have to be configured. Once it has to be configured, then it doesn't matter whether it uses the list of registration domains or not, although certainly one way to make this work would be to have a UI that presents that list and allows the user to choose one entry. > 3. It=E2=80=99s not clear to me from the document about the TTL values. T= he life > of the registration is handled by the Update Lease Time and the Instance > Lease Time. Therefore, I think the document is saying (after talking to > Stuart) that the TTL in the registration is the one the client wants the > server to use in responses. But the server is keeping the registration fo= r > longer than the TTL based on the EDNS(0) Update Lease Option values. > Yes, TTL and leases are completely different things. > So does the server start the TTL countdown on the first response and then > subsequent responses use the decrementing TTL until it times out and then > the server resets it to the TTL it received in the register on the next > response? This is confusing to me even after talking to Stuart so I=E2=80= =9Dm > probably just missing something. > TTLs are used by caches. The server always sends the same TTL. > 4. Section 3 (security considerations) > > You limit the scope of this to within an administrative domain limiting > it=E2=80=99s applicability but nowhere else in the document do you convey= this. For > most of the document, the reader may assume that registrations can be don= e > from anywhere, may wonder why they aren=E2=80=99t encrypted, and then onl= y see in > the security section that this is really made for IoT devices and in the > home. > I think the name of the protocol should reflect this limited scope instea= d > of using a generic name like Service Registration Protocol since it isn= =E2=80=99t > designed to be used as a generic unicast service registration protocol. > Maybe something like Local Service Registration Protocol or Site Service > Registration Protocol or Constrained Service Registration Protocol or > something better than I can=E2=80=99t think of right now, > I don't see the point in this. If we want to make it possible to register services from outside of the administrative domain, we can add an extension to do that, but it doesn't really make sense to have a service registration protocol that takes the place of an administrator, but that spans administrative domains. If we had an authenticated service registration protocol, it would just be this protocol plus some additional stuff to allow enrolled devices to register when not local. So I think making the base spec have a name that is limiting in this way would send exactly the wrong message. --000000000000b17b1005711475fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 15, 2018 at 9:55 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Some quick feedback on the lat= est version:
Thanks! :)
=C2=A0
1. You reference mDNS but don=E2=80=99t define it as multicast DNS or refer= ence RFC 6762.

We do reference RFC6762 = in the introduction, but you're right that we don't introduce the t= erm properly.
=C2=A0
2. Section 2, second paragraph, you mention registering with the default re= gistration domain ("dr._dns-sd._udp=E2=80=9D).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. You could add Section 11 to the RFC 6763 ref= erence.

Good point, thanks.
= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. You don=E2=80=99t specify if you should use = the .local domain or another domain. If it=E2=80=99s another domain, how do= you find that domain?

We specify that = you should discover the default registration domain and use that.=C2=A0 =C2= =A0It sounds like this wasn't sufficiently clear, though.=C2=A0 :)
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. Why do you recommend always using the defaul= t registration domain? Couldn=E2=80=99t you get the list of registration do= mains ("r._dns-sd._udp=E2=80=9D) and pick one of those?

This is an automatic protocol, so that would have to = be configured.=C2=A0 =C2=A0Once it has to be configured, then it doesn'= t matter whether it uses the list of registration domains or not, although = certainly one way to make this work would be to have a UI that presents tha= t list and allows the user to choose one entry.
=C2=A0
3. It=E2=80=99s not clear to me from the document about the TTL values. The= life of the registration is handled by the Update Lease Time and the Insta= nce Lease Time. Therefore, I think the document is saying (after talking to= Stuart) that the TTL in the registration is the one the client wants the s= erver to use in responses. But the server is keeping the registration for l= onger than the TTL based on the EDNS(0) Update Lease Option values.

Yes, TTL and leases are completely different t= hings.
=C2=A0
So does the ser= ver start the TTL countdown on the first response and then subsequent respo= nses use the decrementing TTL until it times out and then the server resets= it to the TTL it received in the register on the next response? This is co= nfusing to me even after talking to Stuart so I=E2=80=9Dm probably just mis= sing something.

TTLs are used by caches= .=C2=A0 =C2=A0The server always sends the same TTL.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">4. Section 3 (security considerations)

You limit the scope of this to within an administrative domain limiting it= =E2=80=99s applicability but nowhere else in the document do you convey thi= s. For most of the document, the reader may assume that registrations can b= e done from anywhere, may wonder why they aren=E2=80=99t encrypted, and the= n only see in the security section that this is really made for IoT devices= and in the home.
I think the name of the protocol should reflect this limited scope instead = of using a generic name like Service Registration Protocol since it isn=E2= =80=99t designed to be used as a generic unicast service registration proto= col. Maybe something like Local Service Registration Protocol or Site Servi= ce Registration Protocol or Constrained Service Registration Protocol or so= mething better than I can=E2=80=99t think of right now,

I don't see the point in this.=C2=A0 =C2=A0If we want = to make it possible to register services from outside of the administrative= domain, we can add an extension to do that, but it doesn't really make= sense to have a service registration protocol that takes the place of an a= dministrator, but that spans administrative domains.=C2=A0 =C2=A0If we had = an authenticated service registration protocol, it would just be this proto= col plus some additional stuff to allow enrolled devices to register when n= ot local.=C2=A0 =C2=A0So I think making the base spec have a name that is l= imiting in this way would send exactly the wrong message.
=
--000000000000b17b1005711475fe-- From nobody Sun Jul 15 19:31:55 2018 Return-Path: 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 E630A130F25 for ; Sun, 15 Jul 2018 19:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 IRiKntlUmbvJ for ; Sun, 15 Jul 2018 19:31:50 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 3A0F9130E72 for ; Sun, 15 Jul 2018 19:31:50 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h2-v6so16949621itj.1 for ; Sun, 15 Jul 2018 19:31: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=vt49laeriP4kUgUHDRwEpzlq+l6jT/KLki4aCxyTa2I=; b=ZxMQMj8ZzGV8pR70dWqgVplNOkxPi+OSqGSernEWuWhPoI4wqi6h6d9yVw9cpLmNel rockzOizTfbVlx1n1w/Jk2v9nDZ438OWTd2qeNazFOpGKH2Vq5/ee9IPZbVgzCtkZ3aa j8tEsblgnH5YQy98U0ASBLkfsYIrZTw6VXg8K4rvh6FCr/zdrOoAVNsi97LLSgCXc4nU QdiWFJpxxvSB10akoX418VxBKuw7wINEF/v0J7Go63gRzqEtLZEG8+GfevrxwJxBNOPd W5sBYacgW0X3bpSPVOm5m8mGewVro14FwYZipWNNwAaC+XP+YA7XRa2rpYnJoezcPPRJ 5utQ== 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=vt49laeriP4kUgUHDRwEpzlq+l6jT/KLki4aCxyTa2I=; b=qy+qld/hVPmjEba4MWjCgWR8Kyzmt8UZGhfGl64hAMufNpVX797ogmbfe2bkXMM0Qt hMAvMr+jX24Syznv9R24IrSjzQe2b8V2Yq3uDDX1kcAbeq6FF+FWV16+HNz6so7k3nLv zzpL+ZFxXyYXYodRReVYmUj5cba13tMHFegahlyX/m8+JG0JKuKWtXgPNJIQrGCTvlp1 NTuKVXM2j2zKYYC3NKNXQrQWJd9UjBK++JJJq7iryvRez17pQkmuVBO/9+6luw1ReTMu GvpB925IIhcW5QYkGUrC8tt7/v41re4WLA67D3Sldlc26uSqRGL/DgNsJVoPNn5mr+/Q SIeA== X-Gm-Message-State: AOUpUlH70wf1u8WEJTIDndL+jpeWJ7eBkSAxijDHn84OMJQxEOALjV4f jJ6wQNmobPF6u2du0RvkqEE0HEkqrmsRHYzl+zgrAmAk X-Google-Smtp-Source: AAOMgpcq7Dh5YkUJFT0YLixNkz7JNeyd8XRCKTVJPOsYTMjhOdKbKEqVZdvBIQwUxzC955sU1hIMVUv0CEJ7V0zZjOk= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr12260700jad.38.1531708309584; Sun, 15 Jul 2018 19:31:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 19:31:09 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Sun, 15 Jul 2018 22:31:09 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000b1574a057114a1fc" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 02:31:53 -0000 --000000000000b1574a057114a1fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here are some proposed fixes to the issues you've raised: https://github.com/StuartCheshire/draft-sctl-service-registration/commit/f5= 32e4aee9aaae8f1fccc104df8ea12c450bc0ab On Sun, Jul 15, 2018 at 10:18 PM, Ted Lemon wrote: > On Sun, Jul 15, 2018 at 9:55 PM, Tom Pusateri wrote: > >> Some quick feedback on the latest version: >> > Thanks! :) > > >> 1. You reference mDNS but don=E2=80=99t define it as multicast DNS or re= ference >> RFC 6762. >> > > We do reference RFC6762 in the introduction, but you're right that we > don't introduce the term properly. > > >> 2. Section 2, second paragraph, you mention registering with the default >> registration domain ("dr._dns-sd._udp=E2=80=9D). >> >> a. You could add Section 11 to the RFC 6763 reference. >> > > Good point, thanks. > > >> b. You don=E2=80=99t specify if you should use the .local domain= or >> another domain. If it=E2=80=99s another domain, how do you find that dom= ain? >> > > We specify that you should discover the default registration domain and > use that. It sounds like this wasn't sufficiently clear, though. :) > > >> c. Why do you recommend always using the default registration >> domain? Couldn=E2=80=99t you get the list of registration domains >> ("r._dns-sd._udp=E2=80=9D) and pick one of those? >> > > This is an automatic protocol, so that would have to be configured. Onc= e > it has to be configured, then it doesn't matter whether it uses the list = of > registration domains or not, although certainly one way to make this work > would be to have a UI that presents that list and allows the user to choo= se > one entry. > > >> 3. It=E2=80=99s not clear to me from the document about the TTL values. = The life >> of the registration is handled by the Update Lease Time and the Instance >> Lease Time. Therefore, I think the document is saying (after talking to >> Stuart) that the TTL in the registration is the one the client wants the >> server to use in responses. But the server is keeping the registration f= or >> longer than the TTL based on the EDNS(0) Update Lease Option values. >> > > Yes, TTL and leases are completely different things. > > >> So does the server start the TTL countdown on the first response and the= n >> subsequent responses use the decrementing TTL until it times out and the= n >> the server resets it to the TTL it received in the register on the next >> response? This is confusing to me even after talking to Stuart so I=E2= =80=9Dm >> probably just missing something. >> > > TTLs are used by caches. The server always sends the same TTL. > > >> 4. Section 3 (security considerations) >> >> You limit the scope of this to within an administrative domain limiting >> it=E2=80=99s applicability but nowhere else in the document do you conve= y this. For >> most of the document, the reader may assume that registrations can be do= ne >> from anywhere, may wonder why they aren=E2=80=99t encrypted, and then on= ly see in >> the security section that this is really made for IoT devices and in the >> home. >> I think the name of the protocol should reflect this limited scope >> instead of using a generic name like Service Registration Protocol since= it >> isn=E2=80=99t designed to be used as a generic unicast service registrat= ion >> protocol. Maybe something like Local Service Registration Protocol or Si= te >> Service Registration Protocol or Constrained Service Registration Protoc= ol >> or something better than I can=E2=80=99t think of right now, >> > > I don't see the point in this. If we want to make it possible to > register services from outside of the administrative domain, we can add a= n > extension to do that, but it doesn't really make sense to have a service > registration protocol that takes the place of an administrator, but that > spans administrative domains. If we had an authenticated service > registration protocol, it would just be this protocol plus some additiona= l > stuff to allow enrolled devices to register when not local. So I think > making the base spec have a name that is limiting in this way would send > exactly the wrong message. > --000000000000b1574a057114a1fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jul 15, 2018 at 10:18 PM, Ted Lemon <mellon@fugue.= com> wrote:
On= Sun, Jul 15, 2018 at 9:55 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
Some quick feedback on the= latest version:
Thanks! :)
=C2=A0
1. You reference mDNS but don=E2=80=99t define it as multicast DNS or refer= ence RFC 6762.

We do reference R= FC6762 in the introduction, but you're right that we don't introduc= e the term properly.
=C2=A0
2. Section 2, second paragraph, you mention registering with the default re= gistration domain ("dr._dns-sd._udp=E2=80=9D).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. You could add Section 11 to the RFC 6763 ref= erence.

Good point, thanks.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. You don=E2=80=99t specify if you should use = the .local domain or another domain. If it=E2=80=99s another domain, how do= you find that domain?

We specif= y that you should discover the default registration domain and use that.=C2= =A0 =C2=A0It sounds like this wasn't sufficiently clear, though.=C2=A0 = :)
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. Why do you recommend always using the defaul= t registration domain? Couldn=E2=80=99t you get the list of registration do= mains ("r._dns-sd._udp=E2=80=9D) and pick one of those?

This is an automatic protocol, so that would h= ave to be configured.=C2=A0 =C2=A0Once it has to be configured, then it doe= sn't matter whether it uses the list of registration domains or not, al= though certainly one way to make this work would be to have a UI that prese= nts that list and allows the user to choose one entry.
=C2=A0
3. It=E2=80=99s not clear to me from the document about the TTL values. The= life of the registration is handled by the Update Lease Time and the Insta= nce Lease Time. Therefore, I think the document is saying (after talking to= Stuart) that the TTL in the registration is the one the client wants the s= erver to use in responses. But the server is keeping the registration for l= onger than the TTL based on the EDNS(0) Update Lease Option values.

Yes, TTL and leases are completely diff= erent things.
=C2=A0
So does the server start the TTL countdown on the first response a= nd then subsequent responses use the decrementing TTL until it times out an= d then the server resets it to the TTL it received in the register on the n= ext response? This is confusing to me even after talking to Stuart so I=E2= =80=9Dm probably just missing something.

TTLs are used by caches.=C2=A0 =C2=A0The server always sends the s= ame TTL.
=C2=A0
4. Section 3 (security considerations)

You limit the scope of this to within an administrative domain limiting it= =E2=80=99s applicability but nowhere else in the document do you convey thi= s. For most of the document, the reader may assume that registrations can b= e done from anywhere, may wonder why they aren=E2=80=99t encrypted, and the= n only see in the security section that this is really made for IoT devices= and in the home.
I think the name of the protocol should reflect this limited scope instead = of using a generic name like Service Registration Protocol since it isn=E2= =80=99t designed to be used as a generic unicast service registration proto= col. Maybe something like Local Service Registration Protocol or Site Servi= ce Registration Protocol or Constrained Service Registration Protocol or so= mething better than I can=E2=80=99t think of right now,

I don't see the point in this.=C2=A0 =C2=A0If w= e want to make it possible to register services from outside of the adminis= trative domain, we can add an extension to do that, but it doesn't real= ly make sense to have a service registration protocol that takes the place = of an administrator, but that spans administrative domains.=C2=A0 =C2=A0If = we had an authenticated service registration protocol, it would just be thi= s protocol plus some additional stuff to allow enrolled devices to register= when not local.=C2=A0 =C2=A0So I think making the base spec have a name th= at is limiting in this way would send exactly the wrong message.

--000000000000b1574a057114a1fc-- From nobody Sun Jul 15 19:44:57 2018 Return-Path: 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 2A9AC130F25 for ; Sun, 15 Jul 2018 19:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j396EdByseHV for ; Sun, 15 Jul 2018 19:44:53 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91AC130F1C for ; Sun, 15 Jul 2018 19:44:52 -0700 (PDT) Received: from [192.168.1.12] (modemcable091.29-131-66.mc.videotron.ca [66.131.29.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 233736ED; Sun, 15 Jul 2018 22:43:12 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2F2D3D09-4FDD-47BD-88DF-E46126C2B422" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 15 Jul 2018 22:44:50 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 02:44:55 -0000 --Apple-Mail=_2F2D3D09-4FDD-47BD-88DF-E46126C2B422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the quick response. > On Jul 15, 2018, at 10:18 PM, Ted Lemon wrote: > =20 > b. You don=E2=80=99t specify if you should use the .local = domain or another domain. If it=E2=80=99s another domain, how do you = find that domain? >=20 > We specify that you should discover the default registration domain = and use that. It sounds like this wasn't sufficiently clear, though. = :) To discover the default registration domain, you need a domain in the = query: dr._dns-sd._udp. domain could be .local or it could be something else. You don=E2=80=99t = specify what to use here. =20 > 3. It=E2=80=99s not clear to me from the document about the TTL = values. The life of the registration is handled by the Update Lease Time = and the Instance Lease Time. Therefore, I think the document is saying = (after talking to Stuart) that the TTL in the registration is the one = the client wants the server to use in responses. But the server is = keeping the registration for longer than the TTL based on the EDNS(0) = Update Lease Option values. >=20 > Yes, TTL and leases are completely different things. > =20 > So does the server start the TTL countdown on the first response and = then subsequent responses use the decrementing TTL until it times out = and then the server resets it to the TTL it received in the register on = the next response? This is confusing to me even after talking to Stuart = so I=E2=80=9Dm probably just missing something. >=20 > TTLs are used by caches. The server always sends the same TTL. Ok. Should there be any checking on the server to make sure the TTL is = valid from the client. The only advice is make sure the TTL is the same = for every record in the RRset. Should the server make sure it is <=3D to = the lease lifetime or any other checks instead of just blindly accepting = the value from the client? If the TTL value is greater than the lease = lifetime, what error should the server return for the registration? =20 > =20 > 4. Section 3 (security considerations) >=20 > You limit the scope of this to within an administrative domain = limiting it=E2=80=99s applicability but nowhere else in the document do = you convey this. For most of the document, the reader may assume that = registrations can be done from anywhere, may wonder why they aren=E2=80=99= t encrypted, and then only see in the security section that this is = really made for IoT devices and in the home. > I think the name of the protocol should reflect this limited scope = instead of using a generic name like Service Registration Protocol since = it isn=E2=80=99t designed to be used as a generic unicast service = registration protocol. Maybe something like Local Service Registration = Protocol or Site Service Registration Protocol or Constrained Service = Registration Protocol or something better than I can=E2=80=99t think of = right now, >=20 > I don't see the point in this. If we want to make it possible to = register services from outside of the administrative domain, we can add = an extension to do that, but it doesn't really make sense to have a = service registration protocol that takes the place of an administrator, = but that spans administrative domains. If we had an authenticated = service registration protocol, it would just be this protocol plus some = additional stuff to allow enrolled devices to register when not local. = So I think making the base spec have a name that is limiting in this way = would send exactly the wrong message. I disagree. By admitting you need an extension, you are proving my = point. Thanks, Tom --Apple-Mail=_2F2D3D09-4FDD-47BD-88DF-E46126C2B422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the quick response.

On Jul = 15, 2018, at 10:18 PM, Ted Lemon <mellon@fugue.com> wrote:
 
        b. You don=E2=80=99t specify if you should = use the .local domain or another domain. If it=E2=80=99s another domain, = how do you find that domain?

We specify that you = should discover the default registration domain and use that.  =  It sounds like this wasn't sufficiently clear, though.  = :)

To = discover the default registration domain, you need a domain in the = query: dr._dns-sd._udp.<domain>

domain could be .local or it could be something = else. You don=E2=80=99t specify what to use here.
 
3. It=E2=80=99s not clear to me from the document about the TTL values. = The life of the registration is handled by the Update Lease Time and the = Instance Lease Time. Therefore, I think the document is saying (after = talking to Stuart) that the TTL in the registration is the one the = client wants the server to use in responses. But the server is keeping = the registration for longer than the TTL based on the EDNS(0) Update = Lease Option values.

Yes, TTL and leases are completely = different things.
 
So does the server start the TTL countdown on = the first response and then subsequent responses use the decrementing = TTL until it times out and then the server resets it to the TTL it = received in the register on the next response? This is confusing to me = even after talking to Stuart so I=E2=80=9Dm probably just missing = something.

TTLs are used by caches.  =  The server always sends the same = TTL.

Ok. = Should there be any checking on the server to make sure the TTL is valid = from the client. The only advice is make sure the TTL is the same for = every record in the RRset. Should the server make sure it is <=3D to = the lease lifetime or any other checks instead of just blindly accepting = the value from the client? If the TTL value is greater than the lease = lifetime, what error should the server return for the = registration?
 
 
4. Section 3 (security considerations)

You limit the scope of this to within an administrative domain limiting = it=E2=80=99s applicability but nowhere else in the document do you = convey this. For most of the document, the reader may assume that = registrations can be done from anywhere, may wonder why they aren=E2=80=99= t encrypted, and then only see in the security section that this is = really made for IoT devices and in the home.
I think the name of the protocol should reflect this limited scope = instead of using a generic name like Service Registration Protocol since = it isn=E2=80=99t designed to be used as a generic unicast service = registration protocol. Maybe something like Local Service Registration = Protocol or Site Service Registration Protocol or Constrained Service = Registration Protocol or something better than I can=E2=80=99t think of = right now,

I don't see the point in this.  =  If we want to make it possible to register services from outside = of the administrative domain, we can add an extension to do that, but it = doesn't really make sense to have a service registration protocol that = takes the place of an administrator, but that spans administrative = domains.   If we had an authenticated service registration = protocol, it would just be this protocol plus some additional stuff to = allow enrolled devices to register when not local.   So I = think making the base spec have a name that is limiting in this way = would send exactly the wrong message.

I disagree. By admitting you need = an extension, you are proving my point.

Thanks,
Tom


= --Apple-Mail=_2F2D3D09-4FDD-47BD-88DF-E46126C2B422-- From nobody Sun Jul 15 20:08:22 2018 Return-Path: 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 03D6B130F35 for ; Sun, 15 Jul 2018 20:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 E0741Lj3-jy8 for ; Sun, 15 Jul 2018 20:08:18 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 8EA9F130E67 for ; Sun, 15 Jul 2018 20:08:18 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id w16-v6so18862579ita.0 for ; Sun, 15 Jul 2018 20:08:18 -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=7jbj4PHSjX3o18ukFC8/TdIwW8tJtolURT4p30m8t0A=; b=DStroOqAXqVMPe+qoD5k7siDtm4uX7j9nXxUgjCvxGTF9Rr8/Pk2HerqG61arJ0m4c HcSaPRMhJrhTPCcZgpeHNa2rD9dr8Gi35UXlT0q8zm+YYqKKYgiztH4ctMCf68Ypu5jE s//yE19vTRdzqxJoQtQbdCU/P2f7idVmu/LidAuy77EIEicpy6QLuTnQpOAfqTQRzd5v fwDdLFHYbNT3u1ZXpwwXKzYpATs0wBtbpsjeC9UmjNDag8E7/dd0l/+8PgOQUIyuEvlC GYxsy3kXyjgEKrJEy9nml+G6KxgwtTOI6tM4PAxmSPaal+h+1LUePpJnzPFbLcLsPCek A5OA== 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=7jbj4PHSjX3o18ukFC8/TdIwW8tJtolURT4p30m8t0A=; b=lGYxNXbk/6pFnprum2GN6O9oYw0fCOx/N5AAIY4vOJ16n1w/HkbdQiyrnzJtn4FZaD HnDewbMnfG/9NoJa1alT5YoRtvD9Lt8P17UkmRlUKyF29VWkEFJGWcIqA8SjdWJR3QI2 GXuPVFXlXUJPGJJrqrjl/Si2tyiYpcWRqOKDOhG97DFZeklh2g83HKtcQPN9B8El+Bf/ yQYOh7fM6dq6PiZsVFh5zyssAA8SOnffArBcAOc1YAFKf+OKlqzoLZSdCQ7D1jLr4GEt BfSaUNlXvdWDkYVdEd7hzI2wQ6NaTJ8JdeYw1JMICu/8wYi8l/MnFDoqjn4bxhsplhYv Ytlw== X-Gm-Message-State: AOUpUlGah+VC4oreXF+vUeU41bJ2i8QOZfRfXoU8UwIqEyomBdE3xSMu /G6CFwf6Sb/mPnyumDkpYHUPRe4hNz0VTiX0jdiIwQ== X-Google-Smtp-Source: AAOMgpcIOVnWTuYsJAM6EUmddH5H/AO1zpoRP66bcWuRyiGxvh+5bIEyI9EauMkFVmeG0Y3igRX66TKxLOW7+/aLl2w= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr11730804itg.82.1531710497753; Sun, 15 Jul 2018 20:08:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 20:07:37 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Sun, 15 Jul 2018 23:07:37 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000001e28b305711524ec" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 03:08:21 -0000 --0000000000001e28b305711524ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OIC, you mean which domain should be used to discover the default registration domain? Is this better? https://github.com/StuartCheshire/draft-sctl-service-registration/commit/32= 7f3fef292731951c8cc8746b6880f3e13f2e43 On Sun, Jul 15, 2018 at 10:44 PM, Tom Pusateri wrote: > Thanks for the quick response. > > On Jul 15, 2018, at 10:18 PM, Ted Lemon wrote: > > >> b. You don=E2=80=99t specify if you should use the .local domain= or >> another domain. If it=E2=80=99s another domain, how do you find that dom= ain? >> > > We specify that you should discover the default registration domain and > use that. It sounds like this wasn't sufficiently clear, though. :) > > > To discover the default registration domain, you need a domain in the > query: dr._dns-sd._udp. > > domain could be .local or it could be something else. You don=E2=80=99t s= pecify > what to use here. > > > 3. It=E2=80=99s not clear to me from the document about the TTL values. T= he life >> of the registration is handled by the Update Lease Time and the Instance >> Lease Time. Therefore, I think the document is saying (after talking to >> Stuart) that the TTL in the registration is the one the client wants the >> server to use in responses. But the server is keeping the registration f= or >> longer than the TTL based on the EDNS(0) Update Lease Option values. >> > > Yes, TTL and leases are completely different things. > > >> So does the server start the TTL countdown on the first response and the= n >> subsequent responses use the decrementing TTL until it times out and the= n >> the server resets it to the TTL it received in the register on the next >> response? This is confusing to me even after talking to Stuart so I=E2= =80=9Dm >> probably just missing something. >> > > TTLs are used by caches. The server always sends the same TTL. > > > Ok. Should there be any checking on the server to make sure the TTL is > valid from the client. The only advice is make sure the TTL is the same f= or > every record in the RRset. Should the server make sure it is <=3D to the > lease lifetime or any other checks instead of just blindly accepting the > value from the client? If the TTL value is greater than the lease lifetim= e, > what error should the server return for the registration? > > > > >> 4. Section 3 (security considerations) >> >> You limit the scope of this to within an administrative domain limiting >> it=E2=80=99s applicability but nowhere else in the document do you conve= y this. For >> most of the document, the reader may assume that registrations can be do= ne >> from anywhere, may wonder why they aren=E2=80=99t encrypted, and then on= ly see in >> the security section that this is really made for IoT devices and in the >> home. >> I think the name of the protocol should reflect this limited scope >> instead of using a generic name like Service Registration Protocol since= it >> isn=E2=80=99t designed to be used as a generic unicast service registrat= ion >> protocol. Maybe something like Local Service Registration Protocol or Si= te >> Service Registration Protocol or Constrained Service Registration Protoc= ol >> or something better than I can=E2=80=99t think of right now, >> > > I don't see the point in this. If we want to make it possible to > register services from outside of the administrative domain, we can add a= n > extension to do that, but it doesn't really make sense to have a service > registration protocol that takes the place of an administrator, but that > spans administrative domains. If we had an authenticated service > registration protocol, it would just be this protocol plus some additiona= l > stuff to allow enrolled devices to register when not local. So I think > making the base spec have a name that is limiting in this way would send > exactly the wrong message. > > > I disagree. By admitting you need an extension, you are proving my point. > > Thanks, > Tom > > > --0000000000001e28b305711524ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OIC, you mean which domain should be used to discover the = default registration domain?


On Sun, Jul 15, 2018 at 10:44 PM, Tom Pusateri <pusateri@ban= gj.com> wrote:
Thanks for the quick= response.

On J= ul 15, 2018, at 10:18 PM, Ted Lemon <mellon@fugue.com> wrote:
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 b. You don=E2=80=99t specify if you should use = the .local domain or another domain. If it=E2=80=99s another domain, how do= you find that domain?

We specify that = you should discover the default registration domain and use that.=C2=A0 =C2= =A0It sounds like this wasn't sufficiently clear, though.=C2=A0 :)

To discover the= default registration domain, you need a domain in the query:=C2=A0dr._dns-= sd._udp.<domain>

domain could be .local= or it could be something else. You don=E2=80=99t specify what to use here.=
=C2=A0
3. It=E2=80=99s not clear to me from the document about the TTL values. The= life of the registration is handled by the Update Lease Time and the Insta= nce Lease Time. Therefore, I think the document is saying (after talking to= Stuart) that the TTL in the registration is the one the client wants the s= erver to use in responses. But the server is keeping the registration for l= onger than the TTL based on the EDNS(0) Update Lease Option values.

Yes, TTL and leases are completely different t= hings.
=C2=A0
So does the ser= ver start the TTL countdown on the first response and then subsequent respo= nses use the decrementing TTL until it times out and then the server resets= it to the TTL it received in the register on the next response? This is co= nfusing to me even after talking to Stuart so I=E2=80=9Dm probably just mis= sing something.

TTLs are used by caches= .=C2=A0 =C2=A0The server always sends the same TTL.
=

Ok. Should there be any checking on the = server to make sure the TTL is valid from the client. The only advice is ma= ke sure the TTL is the same for every record in the RRset. Should the serve= r make sure it is <=3D to the lease lifetime or any other checks instead= of just blindly accepting the value from the client? If the TTL value is g= reater than the lease lifetime, what error should the server return for the= registration?
=C2=A0
<= div>=C2=A0
4. Section 3 (security consi= derations)

You limit the scope of this to within an administrative domain limiting it= =E2=80=99s applicability but nowhere else in the document do you convey thi= s. For most of the document, the reader may assume that registrations can b= e done from anywhere, may wonder why they aren=E2=80=99t encrypted, and the= n only see in the security section that this is really made for IoT devices= and in the home.
I think the name of the protocol should reflect this limited scope instead = of using a generic name like Service Registration Protocol since it isn=E2= =80=99t designed to be used as a generic unicast service registration proto= col. Maybe something like Local Service Registration Protocol or Site Servi= ce Registration Protocol or Constrained Service Registration Protocol or so= mething better than I can=E2=80=99t think of right now,

I don't see the point in this.=C2=A0 =C2=A0If we want = to make it possible to register services from outside of the administrative= domain, we can add an extension to do that, but it doesn't really make= sense to have a service registration protocol that takes the place of an a= dministrator, but that spans administrative domains.=C2=A0 =C2=A0If we had = an authenticated service registration protocol, it would just be this proto= col plus some additional stuff to allow enrolled devices to register when n= ot local.=C2=A0 =C2=A0So I think making the base spec have a name that is l= imiting in this way would send exactly the wrong message.
=

I disagree. By admitting you need an ext= ension, you are proving my point.

Thanks,
Tom



--0000000000001e28b305711524ec-- From nobody Mon Jul 16 03:00:39 2018 Return-Path: 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 C9DBC130F83 for ; Mon, 16 Jul 2018 03:00: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 fSIJs0K8oJf5 for ; Mon, 16 Jul 2018 03:00: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 B5252130F2C for ; Mon, 16 Jul 2018 03:00:35 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531735234; bh=92Ge6vm7yhgJ9KrKHjGgge0wCOmaCcT5zProZ8hGNm0=; h=From:To:Subject:In-Reply-To:References:Date:From; b=U9yKB9e7/PoXkFkUbR6bDtv3VnEkBMp38k36C/0ArPPuUJsMNYu4syqBbXgmyP3Eo 328LPdde6SssiAk0VT4juAfUVrwlMqvg/JTZCz+mp79qgVn9dB5Tjita0IgVNDuuuo 7z5FcAjpHB/D4annHDmGW/Zk3BtPbGxmpU9e+WUc8qeg+1T3Tr0ikHRwJhy/qrIiwz I1Pjl8Y07r4A4DbHtsUm7yM9b8kbv4zXBcfbM3HsXz5sL8Um0xdM2gbkNyG0P7vGhJ Ghef1+iLljVbHHClWaJ/ht+cOuctrlDvxSgUu0XRehcMNCmEyvnCIoilWy612iOYyA dGgh89EzvMmNw== To: Ted Lemon , dnssd In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2018 12:00:30 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0vn7b5t.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:00:38 -0000 Ted Lemon writes: > I just submitted an updated version of the service registration > document. If you were planning to read this prior to the meeting and > haven't read it yet, you should definitely read the new version. I > think it's more understandable than the old version, but more > importantly, it's also more correct. Yeah, I agree the changes are an improvement! One minor nit: Section 2.4.2 says "A Registration MUST include at least one Service Name update" - but the listing just above that only mentions "Service Discovery Update", "Service Description Update" and "Host Description Update". Is that supposed to say "MUST include at least one Host Description update"? > Things move fast at the IETF... Occasionally, at least ;) -Toke From nobody Mon Jul 16 05:24:54 2018 Return-Path: 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 E6B06130FFB for ; Mon, 16 Jul 2018 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=timwattenberg-de.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 9jjsY0K56DAQ for ; Mon, 16 Jul 2018 05:24:49 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 AD235130FFE for ; Mon, 16 Jul 2018 05:24:48 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id t3-v6so29812287eds.3 for ; Mon, 16 Jul 2018 05:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timwattenberg-de.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B+2UghJV3wV5ZfuoqSfnHJTMw5gcD2akc2Rb2N00i2Y=; b=fo7E0jqr/TWjrYQ9yKcP/VPYsVKyHuzSTIgfT+8DbGNQ0326XYqw+FOlYsL05WVpcK zYC5QsCcjqZJlu8pAVLPbD4vx3ZhW1R3fAr0Zi2spSbse7bWPomcLP7rIOdAd9M2mR72 kE/H4R7vEwFpN6OfVhJmXDpNo/aSFf6twecD3XOu/IQ7ZTkxn7k/YUxNL98A5wkbJ+FZ dd/IWuJHlaTBM1cnIPrCH5Qy2zaHFc9P55Ymy+DFniPyIxAGKGJxEytIvWuHFleOnobK YA84xP3jmD0zRmZl6pRB68dS8sek1KmQkk/kVLd+djlI0d9Uv0AnpBH6RD0qhpERvH9+ FysA== 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=B+2UghJV3wV5ZfuoqSfnHJTMw5gcD2akc2Rb2N00i2Y=; b=SBnKZiOo27WohySZqwNLOwl12AFFVOy7GNPNy62o3auS1s6oah6iBN1gURGO8clXwp JdEqeh95tGTXc5pOHxsEbncBFB3KBaZEv9CJsMNKS7AafLFQ9yIbor+IHsLCat88IYRm zE53hzsUJQPGpKxZRfLTNgIDNyChkHuWpi4z+M8K3Iiv2tbrEBpkMqse7tORK6/C6Cuw iTSRIih+UzKtvJIR+t5FMKxdSxkkdmoQN1PA3x7RVZx20kIdn+mfo14F9i1RRpoX24Gh KMzZVcTH2zqWqnyRQCARCrhTZUIooBjT/n1zVgp7V1iF5gDpRxoC+S4rNIIr/b4bZljK LtvA== X-Gm-Message-State: AOUpUlEbal8h9xxXRtnBHHYJWgn0OD+4Z4eZP+M2TotzsPtJfMJdLcsW 77s22GAlrm0rYD0Xxr34zqsUs9NTYxm2hI0RVc2N8MzB0/X6oQ== X-Google-Smtp-Source: AAOMgpfwyQP4HA/2B8S0NWXqagmx1MIlxY+uQsW1h79mV6hUbSp7VZEUjAWciZJ80i+Mh5OldtJ7CgiwGcwp2NXTHAI= X-Received: by 2002:a50:c015:: with SMTP id r21-v6mr16895272edb.202.1531743887054; Mon, 16 Jul 2018 05:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8266:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 05:24:46 -0700 (PDT) X-Originating-IP: [96.20.228.137] In-Reply-To: <87d0vn7b5t.fsf@toke.dk> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> From: Tim Wattenberg Date: Mon, 16 Jul 2018 14:24:46 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Ted Lemon , dnssd Content-Type: multipart/alternative; boundary="000000000000466ff305711cead9" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:24:52 -0000 --000000000000466ff305711cead9 Content-Type: text/plain; charset="UTF-8" Ted, I just read through this conversation and the latest version on GitHub. I think you made valuable improvements, especially adding some wording on where the "base-domain" comes from (DHCP/RA). Going through the draft in detail: - 2.3.1 first mentions SIG(0), we might want to add a reference to RFC 2931? - 2.3.2 these server most likely won't support SIG(0) first-come first-served -- we might want to emphasize this at that point? - 2.3.3 (similar to 2.3.2) it might be worthwhile to point out, that these registrations most likely won't be secured - 2.4 general question: Is SIG(0) first-come first-serve protection mandatory to be used by a service which registers itself? Might there be scenario where a service explicitly wants to give other instances the opportunity to overwrite its service registration? - 2.4.1.1/2.4.2 for completeness: should we mention the SIG RR? - 2.4.2 as briefly discussed yesterday: should we mention that the order of of the update-statements does matter? I mean it's clear if the reader is familiar with DNS update, but I thinks it doesn't hurt to also point it out in this draft. - 2.4.2 (naming issue mentioned by Toke): If I understand correctly, it should say "A Registration MUST include at least one Service Discovery update, at least one Service Description update, and exactly one Host Description update." - 3. On the security discussion: I agree with you that the standard behaviour should be limited to the administrative domain -- Tom's use-case might be subject to an extension. Thanks, Tim Tim Wattenberg mail@timwattenberg.de +49 1578 8248731 --000000000000466ff305711cead9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted,

I just read through thi= s conversation and the latest version on GitHub.
I think you made= valuable improvements, especially adding some wording on where the "b= ase-domain" comes from (DHCP/RA).

Going throu= gh the draft in detail:
- 2.3.1 first mentions SIG(0), we might w= ant to add a reference to RFC 2931?
- 2.3.2 these server most lik= ely won't support SIG(0) first-come first-served -- we might want to em= phasize this at that point?
- 2.3.3 (similar to 2.3.2) it might b= e worthwhile to point out, that these registrations most likely won't b= e secured
- 2.4 general question: Is SIG(0) first-come first-serv= e protection mandatory to be used by a service which registers itself? Migh= t there be scenario where a service explicitly wants to give other instance= s the opportunity to overwrite its service registration?
- 2.4.1.1/2.4.2 for completeness: should we me= ntion the SIG RR?
- 2.4.2 as briefly discussed yesterday: should = we mention that the order of of the update-statements does matter? I mean i= t's clear if the reader is familiar with DNS update, but I thinks it do= esn't hurt to also point it out in this draft.
- 2.4.2 (namin= g issue mentioned by Toke): If I understand correctly, it should say "= A Registration MUST include at least one Service Discovery update, at least= one Service Description update, and exactly one Host Description update.&q= uot;
- 3. On the security discussion: I agree with you that t= he standard behaviour should be limited to the administrative domain -- Tom= 's use-case might be subject to an extension.

= Thanks, Tim

Tim Wattenberg
mail@timwattenberg.de
+49 1578 8248731
--000000000000466ff305711cead9-- From nobody Mon Jul 16 05:59:09 2018 Return-Path: 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 A7255129385 for ; Mon, 16 Jul 2018 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 COn1w6cCwxm2 for ; Mon, 16 Jul 2018 05:59:05 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751BF130DF9 for ; Mon, 16 Jul 2018 05:59:05 -0700 (PDT) Received: from dhcp-9194.meeting.ietf.org (dhcp-9194.meeting.ietf.org [31.133.145.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id F0B68779; Mon, 16 Jul 2018 08:57:22 -0400 (EDT) From: Tom Pusateri Message-Id: <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_92A2F957-31DA-410C-A8ED-F107CCFC64A3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 16 Jul 2018 08:59:03 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 12:59:08 -0000 --Apple-Mail=_92A2F957-31DA-410C-A8ED-F107CCFC64A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 15, 2018, at 11:07 PM, Ted Lemon wrote: >=20 > OIC, you mean which domain should be used to discover the default = registration domain? >=20 > Is this better? = https://github.com/StuartCheshire/draft-sctl-service-registration/commit/3= 27f3fef292731951c8cc8746b6880f3e13f2e43 = >=20 Yes, the the dr._dns-sd._udp. part is more clear. Thanks. The TTL addition still leaves ambiguity for the server implementation: "Service Registration servers SHOULD ensure that TTLs are reasonable: = neither too long nor too short. The TTL should never be longer than the = lease time.=E2=80=9D Can you give guidance for =E2=80=9Ctoo short=E2=80=9D? =E2=80=9Ctoo = long=E2=80=9D seems to be > lease time. If this isn=E2=80=99t what you = mean by =E2=80=9Ctoo long=E2=80=9D, guidance on that would be = appreciated too. And finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo = short=E2=80=9D, how does the server respond? Does the server accept the = registration and modify the TTL? Does the server reject the registration = and return an error? What error code? One minor nit. If I understand the distinction correctly, you use = =E2=80=9Cdomain=E2=80=9D if the following places where you should use = =E2=80=9Czone=E2=80=9D: Section 2: However, they can be assumed to be able to provide registration domain = discovery and routing. Section 2.2: As described above, full-featured devices are responsible for knowing in = what domain they should register their services. Thanks, Tom --Apple-Mail=_92A2F957-31DA-410C-A8ED-F107CCFC64A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jul 15, 2018, at 11:07 PM, Ted Lemon <mellon@fugue.com> = wrote:

OIC, you mean which domain should be used to = discover the default registration domain?

Is this better?  https://github.com/StuartCheshire/draft-sctl-service-registrati= on/commit/327f3fef292731951c8cc8746b6880f3e13f2e43


Yes, the the dr._dns-sd._udp.<domain> part = is more clear. Thanks.

The TTL = addition still leaves ambiguity for the server = implementation:

"Service = Registration servers SHOULD ensure that TTLs are reasonable: = neither too long nor too short.  The TTL should never be = longer than the lease time.=E2=80=9D

Can you give guidance for =E2=80=9Ctoo short=E2=80=9D= ? =E2=80=9Ctoo long=E2=80=9D seems to be > lease time. If this = isn=E2=80=99t what you mean by =E2=80=9Ctoo long=E2=80=9D, guidance on = that would be appreciated too.

And = finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo = short=E2=80=9D, how does the server respond? Does the server accept the = registration and modify the TTL? Does the server reject the registration = and return an error? What error code?

One minor nit. If I understand the distinction = correctly, you use =E2=80=9Cdomain=E2=80=9D if the following places = where you should use =E2=80=9Czone=E2=80=9D:

Section 2:

However, they can be assumed to be able to provide = registration domain discovery and routing.

Section 2.2:

As = described above, full-featured devices are responsible for = knowing in what domain they should register their = services.

Thanks,
Tom




= --Apple-Mail=_92A2F957-31DA-410C-A8ED-F107CCFC64A3-- From nobody Mon Jul 16 11:47:17 2018 Return-Path: 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 74C05130E62 for ; Mon, 16 Jul 2018 11:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 w6y8qxW-WySR for ; Mon, 16 Jul 2018 11:47:12 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B58A130E55 for ; Mon, 16 Jul 2018 11:47:12 -0700 (PDT) Received: from [10.244.195.212] (unknown [206.108.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id A0A3D80B; Mon, 16 Jul 2018 14:45:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> Date: Mon, 16 Jul 2018 14:47:08 -0400 Cc: dnssd Content-Transfer-Encoding: quoted-printable Message-Id: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:47:15 -0000 > On Jul 16, 2018, at 8:59 AM, Tom Pusateri wrote: >=20 > The TTL addition still leaves ambiguity for the server implementation: >=20 > "Service Registration servers SHOULD ensure that TTLs are reasonable: = neither too long nor too short. The TTL should never be longer than the = lease time.=E2=80=9D >=20 > Can you give guidance for =E2=80=9Ctoo short=E2=80=9D? =E2=80=9Ctoo = long=E2=80=9D seems to be > lease time. If this isn=E2=80=99t what you = mean by =E2=80=9Ctoo long=E2=80=9D, guidance on that would be = appreciated too. >=20 > And finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo = short=E2=80=9D, how does the server respond? Does the server accept the = registration and modify the TTL? Does the server reject the registration = and return an error? What error code? May I suggest that the server adjusts the TTL to a reasonable value = (guidance) and returns the new value in the response. Then the client can know for the future what is a more acceptable value = and adjust future registrations with this server. New Feedback =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 Section 2 says: 'In other network environments, updates for names ending in = "services.arpa" may be rewritten internally to names with broader = visibility.=E2=80=99 And Section 2.2 says: =E2=80=98...and let the DNS-SD Service Registration server handle = rewriting that to a different domain if necessary.=E2=80=99 When the registration server rewrites the domain, does it send the new = domain back in the response? I couldn=E2=80=99t find that anywhere in = the document. Does it have to send back all of the records in the = request? Can it send just a header if the Zone doesn=E2=80=99t change = and the TTL doesn=E2=80=99t change? Can it only complete the Zone = section if the zone name changes but the TTL stays the same with nothing = changes in the Update section? Section 2.3.3: 'To do so, it must discover default registration zone=E2=80=99 =E2=80=94= =E2=80=94> insert =E2=80=98the=E2=80=99 Section 2.4.2 Page 9: change =E2=80=9Crejectration=E2=80=9D to =E2=80=9Cregistration=E2=80=9D. Throughout the document "DNS-SD Registration Protocol=E2=80=9D is used = synonymously with "DNS-SD Service Registration Protocol=E2=80=9D. If the = latter is too many words, you might substitute =E2=80=98this = specification=E2=80=99. This becomes even more confusing with the = discussion of service registration protocols in RFC 6763 such as: "Service discovery requires a service registration protocol. DNS = already has one: DNS Dynamic Update.=E2=80=9D and "This also requires some service discovery registration protocol = to be implemented and deployed for clients to register with the central = aggregation server. Virtually every company with an IP network already = runs a DNS server, and DNS already has a dynamic registration = protocol.=E2=80=9D This provides additional motivation for a new name. =E2=80=9CRegistrations=E2=80=9D is capitalized lots of places where it = probably shouldn=E2=80=99t be: "Ordinarily Registrations will fail=E2=80=A6= =E2=80=9D Thanks, Tom From nobody Mon Jul 16 11:51:41 2018 Return-Path: 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 26C02130E74 for ; Mon, 16 Jul 2018 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 LPKE6Y4oy05s for ; Mon, 16 Jul 2018 11:51:35 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 92022130E62 for ; Mon, 16 Jul 2018 11:51:35 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z20-v6so38812617iol.0 for ; Mon, 16 Jul 2018 11:51:35 -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=Zivh59WBvx+TE4iNfNPo+Mb4SBGIcJv7Y8budIp/L/Q=; b=qeykWcZIemfLMJf5YvraLxxpkVZEVAby9nrY0gnA64CZ5R/kQPMPcmJifultVX7HzT que7/CT0JtGhzqLhh6dw0Ya/NEyO1JPZMxopMYaLUBcyzCaf76PiX1HccK3nBWZMWrme OHUIsWenQyx4ykOFBYfVgv5ZC6iRP/iHPYBm0r0NfWs08GrGwe+EVXxvSui2Bdb9gPqN 0YLHon1VByP0cJdjQbMW+KSCV+pmxVIxYKUwig7NIXexYLwUyb0/4mE6whTCNhUjZTkN YDq5hLhJqCQa5502AKe69IIeu2hjbKRfE0S64hAsBAbj93Z04ZLqn9bifW6bAuT9vTiF cw+A== 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=Zivh59WBvx+TE4iNfNPo+Mb4SBGIcJv7Y8budIp/L/Q=; b=kShY8AlC9blQl/wCSkblEgLKPQJKTUPU4/PFYHfbZXf7IribNEvYlafEMO2rsLt5y5 co0mhNWfIDCdZAz9n/B6rIIcrdh6CcB0Fz7Y1V3F1yduSlM346tmaNtFDFkYz4Voej50 ypLfkPU7njAAB4oohpH7sjZJMeeWEaLlq/psqWmTGBsGmraE0MVcemXT1tqIoYxi/oBB RyZA0d4+ls85jyqnF+SvTQClVTjyaHnSw9KhpnAGFvVJtt+AJdc8CmgfggfOLCKBEY7a Ex5lMuvTxgjgEjEhF6UQKtVLyCSIP5nSM3HIvU9e1qKfYKU254ZOKFD5o7a5ix6ZI4NR O09w== X-Gm-Message-State: AOUpUlH8km93c9tRdnNi+WgTkrffU1knAa374xDa1xhO7LvbYhFhW7Eq JT+OFqxODSuq3ya8qQNTT6qBZOSgZ9GBc7mUe0lvbQ== X-Google-Smtp-Source: AAOMgpfnDmi16MkQaqfWuqg5ZZ+ujEchu8zlmLHtMChqqfzWaKHCqKxYrjRAVkACKEmLXVWcH/Mdi0yUeKjsZqG+f8I= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr987302ioe.32.1531767094632; Mon, 16 Jul 2018 11:51:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:50:54 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> From: Ted Lemon Date: Mon, 16 Jul 2018 14:50:54 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000008e099405712251ef" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:51:39 -0000 --0000000000008e099405712251ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't know, I kind of like rejectration. It has a certain classy ring to it that you don't get with a more pedestrian word like "registration." :) My intention with "Registration" was for it to be referring to any message from the service to the DNS-SD Registration server. So the capitalization was intentional. But I agree that the term is a bit too generic; it might be better if we could come up with a term that didn't need to be capitalized to make it stand out. Maybe "rejectration?" (Just Kidding... :) On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri wrote: > > > > On Jul 16, 2018, at 8:59 AM, Tom Pusateri wrote: > > > > The TTL addition still leaves ambiguity for the server implementation: > > > > "Service Registration servers SHOULD ensure that TTLs are reasonable: > neither too long nor too short. The TTL should never be longer than the > lease time.=E2=80=9D > > > > Can you give guidance for =E2=80=9Ctoo short=E2=80=9D? =E2=80=9Ctoo lon= g=E2=80=9D seems to be > lease > time. If this isn=E2=80=99t what you mean by =E2=80=9Ctoo long=E2=80=9D, = guidance on that would be > appreciated too. > > > > And finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo s= hort=E2=80=9D, how does the > server respond? Does the server accept the registration and modify the TT= L? > Does the server reject the registration and return an error? What error > code? > > May I suggest that the server adjusts the TTL to a reasonable value > (guidance) and returns the new value in the response. > > Then the client can know for the future what is a more acceptable value > and adjust future registrations with this server. > > New Feedback > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > Section 2 says: > > 'In other network environments, updates for names ending in > "services.arpa" may be rewritten internally to names with broader > visibility.=E2=80=99 > > And Section 2.2 says: > > =E2=80=98...and let the DNS-SD Service Registration server handle rewriti= ng that > to a different domain if necessary.=E2=80=99 > > When the registration server rewrites the domain, does it send the new > domain back in the response? I couldn=E2=80=99t find that anywhere in the= document. > Does it have to send back all of the records in the request? Can it send > just a header if the Zone doesn=E2=80=99t change and the TTL doesn=E2=80= =99t change? Can it > only complete the Zone section if the zone name changes but the TTL stays > the same with nothing changes in the Update section? > > Section 2.3.3: > > 'To do so, it must discover default registration zone=E2=80=99 =E2=80= =94=E2=80=94> insert =E2=80=98the=E2=80=99 > > Section 2.4.2 Page 9: > > change =E2=80=9Crejectration=E2=80=9D to =E2=80=9Cregistration=E2=80=9D. > > Throughout the document "DNS-SD Registration Protocol=E2=80=9D is used > synonymously with "DNS-SD Service Registration Protocol=E2=80=9D. If the = latter is > too many words, you might substitute =E2=80=98this specification=E2=80=99= . This becomes > even more confusing with the discussion of service registration protocols > in RFC 6763 such as: > "Service discovery requires a service registration protocol. DNS > already has one: DNS Dynamic Update.=E2=80=9D and > "This also requires some service discovery registration protocol > to be implemented and deployed for clients to register with the central > aggregation server. Virtually every company with an IP network already > runs a DNS server, and DNS already has a dynamic registration protocol.= =E2=80=9D > This provides additional motivation for a new name. > > =E2=80=9CRegistrations=E2=80=9D is capitalized lots of places where it pr= obably shouldn=E2=80=99t > be: "Ordinarily Registrations will fail=E2=80=A6=E2=80=9D > > Thanks, > Tom > > > --0000000000008e099405712251ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know, I kind of like rejectration.=C2=A0 =C2= =A0It has a certain classy ring to it that you don't get with a more pe= destrian word like "registration."=C2=A0 :)

My= intention with "Registration" was for it to be referring to any = message from the service to the DNS-SD Registration server.=C2=A0 So the ca= pitalization was intentional.=C2=A0 =C2=A0But I agree that the term is a bi= t too generic; it might be better if we could come up with a term that didn= 't need to be capitalized to make it stand out.=C2=A0 =C2=A0Maybe "= ;rejectration?"=C2=A0 =C2=A0(Just Kidding... :)

On Mon, Jul 16, 2018 at 2:4= 7 PM, Tom Pusateri <pusateri@bangj.com> wrote:


> On Jul 16, 2018, at 8:59 AM, Tom Pusateri <pusateri@bangj.com> wrote:
>
> The TTL addition still leaves ambiguity for the server implementation:=
>
> "Service Registration servers SHOULD ensure that TTLs are reasona= ble: neither too long nor too short.=C2=A0 The TTL should never be longer t= han the lease time.=E2=80=9D
>
> Can you give guidance for =E2=80=9Ctoo short=E2=80=9D? =E2=80=9Ctoo lo= ng=E2=80=9D seems to be > lease time. If this isn=E2=80=99t what you mea= n by =E2=80=9Ctoo long=E2=80=9D, guidance on that would be appreciated too.=
>
> And finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo = short=E2=80=9D, how does the server respond? Does the server accept the reg= istration and modify the TTL? Does the server reject the registration and r= eturn an error? What error code?

May I suggest that the server adjusts the TTL to a reasonable value = (guidance) and returns the new value in the response.

Then the client can know for the future what is a more acceptable value and= adjust future registrations with this server.

New Feedback
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94

Section 2 says:

'In other network environments, updates for names ending in "servi= ces.arpa" may be rewritten internally to names with broader visibility= .=E2=80=99

And Section 2.2 says:

=E2=80=98...and let the DNS-SD Service Registration server handle rewriting= that to a different domain if necessary.=E2=80=99

When the registration server rewrites the domain, does it send the new doma= in back in the response? I couldn=E2=80=99t find that anywhere in the docum= ent. Does it have to send back all of the records in the request? Can it se= nd just a header if the Zone doesn=E2=80=99t change and the TTL doesn=E2=80= =99t change? Can it only complete the Zone section if the zone name changes= but the TTL stays the same with nothing changes in the Update section?

Section 2.3.3:

'To do so, it must discover default registration zone=E2=80=99=C2=A0 = =C2=A0=E2=80=94=E2=80=94> insert =E2=80=98the=E2=80=99

Section 2.4.2 Page 9:

change =E2=80=9Crejectration=E2=80=9D to =E2=80=9Cregistration=E2=80=9D.
Throughout the document "DNS-SD Registration Protocol=E2=80=9D is used= synonymously with "DNS-SD Service Registration Protocol=E2=80=9D. If = the latter is too many words, you might substitute =E2=80=98this specificat= ion=E2=80=99. This becomes even more confusing with the discussion of servi= ce registration protocols in RFC 6763 such as:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Service discovery requires a service regi= stration protocol. DNS already has one: DNS Dynamic Update.=E2=80=9D and =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This also requires some service discovery= registration protocol to be implemented and deployed for clients to regist= er with the central aggregation server.=C2=A0 Virtually every company with = an IP network already runs a DNS server, and DNS already has a dynamic regi= stration protocol.=E2=80=9D
This provides additional motivation for a new name.

=E2=80=9CRegistrations=E2=80=9D is capitalized lots of places where it prob= ably shouldn=E2=80=99t be: "Ordinarily Registrations will fail=E2=80= =A6=E2=80=9D

Thanks,
Tom



--0000000000008e099405712251ef-- From nobody Mon Jul 16 12:01:41 2018 Return-Path: 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 749761311A3 for ; Mon, 16 Jul 2018 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WnlAwmvQx1SE for ; Mon, 16 Jul 2018 12:01:30 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34C41311DC for ; Mon, 16 Jul 2018 12:01:29 -0700 (PDT) Received: from [10.244.195.212] (unknown [206.108.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EE573813; Mon, 16 Jul 2018 14:59:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: Date: Mon, 16 Jul 2018 15:01:27 -0400 Cc: dnssd Content-Transfer-Encoding: quoted-printable Message-Id: <6BE0848A-7468-4B70-857F-81D824684D74@bangj.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:01:40 -0000 > On Jul 16, 2018, at 2:50 PM, Ted Lemon wrote: >=20 > I don't know, I kind of like rejectration. It has a certain classy = ring to it that you don't get with a more pedestrian word like = "registration." :) >=20 > My intention with "Registration" was for it to be referring to any = message from the service to the DNS-SD Registration server. So the = capitalization was intentional. But I agree that the term is a bit too = generic; it might be better if we could come up with a term that didn't = need to be capitalized to make it stand out. Maybe "rejectration?" = (Just Kidding... :) Uniqueness is important=E2=80=A6 One more thing, you allocate a special use domain name = =E2=80=98services.arpa=E2=80=99 but there is no IANA section to advise = IANA on the allocation. Thanks, Tom From nobody Mon Jul 16 12:17:31 2018 Return-Path: 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 020E3131186 for ; Mon, 16 Jul 2018 12:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=timwattenberg-de.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 P3afT0gjG0ST for ; Mon, 16 Jul 2018 12:17:27 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 3319C130FAF for ; Mon, 16 Jul 2018 12:17:23 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id b10-v6so3578385eds.4 for ; Mon, 16 Jul 2018 12:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timwattenberg-de.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gRvJvKVZnlxcH7/cG5hRL3uLgJdpyLm8uSu140q3b64=; b=2IMqD4VDeGAd2eZm7bEY6TR82igYfUMWiEsfGgjforukc84pKlbFzUXqSSaPYgnkVI M2MRBVpPRRiYL2//lK811pQShEHa6F6ddqU95ylMOCb2C1DXpFf7Qp4+fv3a8ZSM9Xzl FWeh/FVz/EsoFdmsoLDOZXAeXuN+LdInKlcO8IxubwfMhSWgQt5cy3/TOaEkylj3H3GS gqErA+lB6QOs5+cCN9UjsO+fxsZYErro5mJ70Yq8DK2gRk4QrYzIIrlCUiLkj+kEYA3E mjULkjEUoIrQdiwfKUN9RwrBewSfnWSUBB6OeGc7ZPTj+m7pMCcy5MZeMkus3rHkdH6U osNQ== 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; bh=gRvJvKVZnlxcH7/cG5hRL3uLgJdpyLm8uSu140q3b64=; b=c9mUsOgRKGwHMGQc6u72N8IqsdKQihVSvKS4+MOafSl0Xo0wRWF9FeEgaH+xbCUfEQ zzM2zCiq1PPnAV445HNdV6GSFFDN2hDZWGG+XkDADtVWWk28CAz8UOzT330DYP/4TvKz lYf8pdfsAQ/mgtD2lPpBYLlJTlk/bs38TgDS6HCpmAHzERk1KEzG7onBrwdRPrJtuaAB LbLWqi/x0iLekJZp9JbInQgz/UW7n9cBOVbiV0KS8dtByVUGuZYUB2PVoHJdTyZnEFXQ ftZJ+NrZeIJQfxDxFzpnWVQBDc2E5dwfLAwtFE9Gx4bnKUBxh1TrsXBpNqrZnYipKdmM yuiA== X-Gm-Message-State: AOUpUlGVHBiFGDKEFhe027tLD8zgbRjRIfyul/c42yJ6xkGQt2TGNzbD gJZluNbNPZS6Nau2krT07tvGCvp94bEY6wmws58nm3MpLI8= X-Google-Smtp-Source: AAOMgpcIBJTGWIDD/PMhDjALWEaypojzSff6cD7gXxGuLWvamDCYwAbiNHFVj2vSAmTO2KwltR4ky1PLVNe29+LqmgY= X-Received: by 2002:a50:a846:: with SMTP id j64-v6mr18567270edc.210.1531768641643; Mon, 16 Jul 2018 12:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8266:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 12:17:21 -0700 (PDT) X-Originating-IP: [2001:67c:1232:144:e4f0:45b9:44f8:16a6] In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> From: Tim Wattenberg Date: Mon, 16 Jul 2018 21:17:21 +0200 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="000000000000c37950057122addf" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:17:30 -0000 --000000000000c37950057122addf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-07-16 20:47 GMT+02:00 Tom Pusateri : > Section 2 says: > > 'In other network environments, updates for names ending in > "services.arpa" may be rewritten internally to names with broader > visibility.=E2=80=99 > > And Section 2.2 says: > > =E2=80=98...and let the DNS-SD Service Registration server handle rewriti= ng that > to a different domain if necessary.=E2=80=99 > > When the registration server rewrites the domain, does it send the new > domain back in the response? I couldn=E2=80=99t find that anywhere in the= document. > Does it have to send back all of the records in the request? Can it send > just a header if the Zone doesn=E2=80=99t change and the TTL doesn=E2=80= =99t change? Can it > only complete the Zone section if the zone name changes but the TTL stays > the same with nothing changes in the Update section? > This was in an earlier version of the draft (see https://github.com/ StuartCheshire/draft-sctl-service-registration/blob/ 51b7cb54300fea7e44e8e7dee49c17e9f598b3ba/draft-sctl-service- registration.txt#L204): > The response to the DNS Update being used to register the service will > contain the rewritten names, instead of ".local". Subsequent updates shou= ld > still use the ".local" domain and not the registration domain, since the > registration domain may change over time or when the service is physicall= y > moved to a new network. > However it got removed with the following iteration when moving to the "services.arpa" domain. --000000000000c37950057122addf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018-07-16 20:47 GMT+02:00 Tom Pusateri <pusateri@bangj.com>:
Section 2 says:

'In other network environments, updates for names ending in=20 "services.arpa" may be rewritten internally to names with broader= =20 visibility.=E2=80=99

And Section 2.2 says:

=E2=80=98...and let the DNS-SD Service Registration server handle rewriting= that to a different domain if necessary.=E2=80=99

When the registration server rewrites the domain, does it send the new=20 domain back in the response? I couldn=E2=80=99t find that anywhere in the= =20 document. Does it have to send back all of the records in the request?=20 Can it send just a header if the Zone doesn=E2=80=99t change and the TTL do= esn=E2=80=99t change? Can it only complete the Zone section if the zone name changes=20 but the TTL stays the same with nothing changes in the Update section?
<= /blockquote>


However it got= removed with the following iteration when moving to the "services.arp= a" domain.
--000000000000c37950057122addf-- From nobody Mon Jul 16 14:20:56 2018 Return-Path: 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 8DB1F131250 for ; Mon, 16 Jul 2018 14:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 0tQIby_GRNRb for ; Mon, 16 Jul 2018 14:20:43 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 E19CF131258 for ; Mon, 16 Jul 2018 14:20:38 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id q19-v6so39213772ioh.11 for ; Mon, 16 Jul 2018 14:20:38 -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=e1CU/KR/DOLqDQvvjKTGPbT7Osmtyiyy8UWCxdvmDZc=; b=m7KpKLMPKugXw2cpS/Ojo5tuRq4b9H5XhSUGyRi9nqOUcivNb7oE1pKjhjja3FWjQ2 7DVyVjGU2gOlBDRYu3ric8WuAZZoLv9cTeiUWpcULAq0pgfCYvw8YUu33VbMJ561VllG JlgsFYfdpnT3hZZU2pFPRHJ89ls69kc7GksD0ADyvLczDHZiTEdILF6gV+Gu1t8NwG6r CFXVmU0SuWxidFHb5eN07OCwqJC5YLS12ATzENm/m86N8E6DUCnMq8OpM23bXOhgYi6b hRKICWbju8TkYebzZFiQe4qx7Liu/focpQewKBe+Erpd5ZvWfBoFpfW806pCI5KWgCHK tIMg== 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=e1CU/KR/DOLqDQvvjKTGPbT7Osmtyiyy8UWCxdvmDZc=; b=b16lE35h6oPXEBnem/ioL8xzI1ptRDnZ46aUVTbvWXWcHYx+HwMjEyMtJZxa/d19eN 8T5tiUKMcwI/wpUoTpKDGAXltZYgsVdT4TKuj7vx7Skr2976P5zqk6V4werOU4O3QCcu oT56FJRwjQVnumFD+0AZxToHA2xCKm79VF1BJqGO4Bx7/k1e9Df9ZWhmumPkg59EQmI+ gH75tkyFOzfyrkni1Q9POFcR1TzmhN1FhD4/QVyv5CZSWtLDba90RAc6qRt2PlwJwvTk DB4L5dVbRGEh6QAXsOGhnQuT6lQQzO6aZlkLl2WbMcaAZv8NCeYEvk2OQSjkBWjOS22I LYAA== X-Gm-Message-State: AOUpUlHXR6tJwwBKSiQATOyytpw0MsphlzqXNg53T/5mJHOGmWWPqnVo FhLZbdfARAQOHWRt/S/8gYU5Cqpna0iP/2zd9nMq+buP X-Google-Smtp-Source: AAOMgpe7PKgq6jMByirO5cP3I9mud6duyKXWIN13HbfzuJO5kWYyMz2HxC9hEHtpZ8OQ89mre6Bbn0a2TxRgJJwqJ/I= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr43015366ioe.85.1531776038043; Mon, 16 Jul 2018 14:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:19:57 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> From: Ted Lemon Date: Mon, 16 Jul 2018 17:19:57 -0400 Message-ID: To: Tim Wattenberg Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , dnssd Content-Type: multipart/alternative; boundary="0000000000009f9c3f0571246694" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:20:55 -0000 --0000000000009f9c3f0571246694 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 16, 2018 at 8:24 AM, Tim Wattenberg wrote: > > I just read through this conversation and the latest version on GitHub. > I think you made valuable improvements, especially adding some wording on > where the "base-domain" comes from (DHCP/RA). > > Going through the draft in detail: > - 2.3.1 first mentions SIG(0), we might want to add a reference to RFC > 2931? > Done (not yet committed) > - 2.3.2 these server most likely won't support SIG(0) first-come > first-served -- we might want to emphasize this at that point? > I added text. - 2.3.3 (similar to 2.3.2) it might be worthwhile to point out, that these > registrations most likely won't be secured > I think this is unnecessary. In order for such an update to be done, it would have to be accompanied with whatever authentication the server being updated requires. > - 2.4 general question: Is SIG(0) first-come first-serve protection > mandatory to be used by a service which registers itself? Might there be > scenario where a service explicitly wants to give other instances the > opportunity to overwrite its service registration? > I think defining a semantics for this that would not be hugely problematic is difficult and definitely out of scope for this work. > - 2.4.1.1/2.4.2 for completeness: should we mention the SIG RR? > What would we say? > - 2.4.2 as briefly discussed yesterday: should we mention that the order > of of the update-statements does matter? I mean it's clear if the reader is > familiar with DNS update, but I thinks it doesn't hurt to also point it out > in this draft. > I added this: Order matters in DNS updates. Specifically, deletes must precede adds for records that the deletes would affect; otherwise the add will have no effect. > - 2.4.2 (naming issue mentioned by Toke): If I understand correctly, it > should say "A Registration MUST include at least one Service Discovery > update, at least one Service Description update, and exactly one Host > Description update." > Yes, fixed. --0000000000009f9c3f0571246694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 8:24 AM, Tim Wattenberg <mail@timwattenberg.de> wrote:
I just read through this conversation and the latest versi= on on GitHub.
I think you made valuable improvements, especially = adding some wording on where the "base-domain" comes from (DHCP/R= A).

Going through the draft in detail:
-= 2.3.1 first mentions SIG(0), we might want to add a reference to RFC 2931?=
Done (not yet committed)
=C2=A0
-= 2.3.2 these server most likely won't support SIG(0) first-come first-s= erved -- we might want to emphasize this at that point?
=C2=A0I added text.

- 2.3.3 (similar to 2.3.2) i= t might be worthwhile to point out, that these registrations most likely wo= n't be secured

I think this= is unnecessary.=C2=A0 =C2=A0In order for such an update to be done, it wou= ld have to be accompanied with whatever authentication the server being upd= ated requires.
=C2=A0
- 2.4 general question: Is SIG(0) fir= st-come first-serve protection mandatory to be used by a service which regi= sters itself? Might there be scenario where a service explicitly wants to g= ive other instances the opportunity to overwrite its service registration?<= /div>

I think defining a semantics fo= r this that would not be hugely problematic is difficult and definitely out= of scope for this work.
=C2=A0
- 2.4.1.1/2.4.2 for completeness: should we mention= the SIG RR?

What would we say?=
=C2=A0
- 2.4.2 as briefly discussed yesterday: should we menti= on that the order of of the update-statements does matter? I mean it's = clear if the reader is familiar with DNS update, but I thinks it doesn'= t hurt to also point it out in this draft.
I added this:
=C2=A0 Order matters in DNS updates.=C2=A0 Specifically, deletes must prec= ede adds for records that the deletes
=C2=A0 would affect; otherwise the add will have no effect.<= ;/t>
=C2=A0
- 2.4.2 (naming issue mentioned by Toke): If I u= nderstand correctly, it should say "A Registration MUST include at lea= st one Service Discovery update, at least one Service Description update, a= nd exactly one Host Description update."
<= div>
Yes, fixed.
=C2=A0
--0000000000009f9c3f0571246694-- From nobody Mon Jul 16 14:24:57 2018 Return-Path: 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 735FD131298 for ; Mon, 16 Jul 2018 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 4uOoZmskNAGQ for ; Mon, 16 Jul 2018 14:24:48 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 852BB131258 for ; Mon, 16 Jul 2018 14:24:48 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q19-v6so39224093ioh.11 for ; Mon, 16 Jul 2018 14:24:48 -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=O1BK84zeVC0OYlLxQ89IJ8z+xwRsblZRXdGEpk4mgJo=; b=yjZEDKUaxHbh3zUHjhFho1jLbbISJmyLZYvKEn2HGivEbmI9IqWq69H6pim6DDF8uE LVuPwNjMdb4uyBDBS6YbkDOrxr/8V3fmmS6fBSXsrZPwc+z3X2dSvYkzizrqylWmz+o5 fPWgGEgyTT0Xc31L+Km63EnWiyg7lG64aPAbMi9ZEs3TmBC5L5idcgj9bLimg/RYQkkZ OD7gkzVTkbfgniLMzq5IaWZV+TBi+/TwPAiOrGNh85rL+g4p0GKCUc99AIbBSvHAnCso +yrcIFx4Peb7Sj0orsAD4b79HytVREKeO0agcHhp9+uD6P2z4K89FWeuQXVrhExNdp25 I96Q== 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=O1BK84zeVC0OYlLxQ89IJ8z+xwRsblZRXdGEpk4mgJo=; b=Fe5GzqzuaStfU5xmsexDfCn9VOCrA+q9u+C0C/qfc+e9eu2JyM240XBo8PDogfAcY/ mW+G5ENa7kcCNZTTYijxp49XgFF2PsBwKhU6lgVIrJVF8qKJIJOWiOcg10Fav3nIYvHu IRtXN7bzmaWD94AYkqVd6W7tmUaTVu1Oqn9m4CWXB//IMQRJ3/yeDYRiFfBM+Kfa5Jtz 7qt+pesm0DKmO0y23sBEvSXTjOJ1WhxEM/Em97M2J3Sy+dtnmdDJR2VSxsCh5yvaWw0d SRntzIurjRG1zqWiNmupe6YQeSYgwu6GEk42wNrfFnla8lpZLy9tsQOKlZUy06JEIY2+ D4aw== X-Gm-Message-State: AOUpUlGaYX4jlC0PS+lkf4A+dN0b6nFEW5xG6l0y/3VRR8rAPAztKn+m 5NTPaP2GxKh3VOni/dfxMZkWFmMnfg2JPtZauYMbBw== X-Google-Smtp-Source: AAOMgpcy3U87AUiHX3D2WDiKVqVWHVmKcY4j4ty6FuAJCXk5YLq+7pxB5b/gFSDMjFyWHQG5wZl7RN2f8E1jPmRjzxQ= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr1422975ioe.32.1531776287883; Mon, 16 Jul 2018 14:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:24:07 -0700 (PDT) In-Reply-To: <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> From: Ted Lemon Date: Mon, 16 Jul 2018 17:24:07 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000083db94057124756c" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:24:55 -0000 --00000000000083db94057124756c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2018 at 8:59 AM, Tom Pusateri wrote: > The TTL addition still leaves ambiguity for the server implementation: > > "Service Registration servers SHOULD ensure that TTLs are reasonable: > neither too long nor too short. The TTL should never be longer than the > lease time.=E2=80=9D > > Can you give guidance for =E2=80=9Ctoo short=E2=80=9D? =E2=80=9Ctoo long= =E2=80=9D seems to be > lease > time. If this isn=E2=80=99t what you mean by =E2=80=9Ctoo long=E2=80=9D, = guidance on that would be > appreciated too. > > And finally, if the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo sho= rt=E2=80=9D, how does the server > respond? Does the server accept the registration and modify the TTL? Does > the server reject the registration and return an error? What error code? > I've added text. The answer is that it's not an error for the SRP Update to contain a TTL that the server doesn't like=E2=80=94if the server doesn't= like it, it just overrides it. > One minor nit. If I understand the distinction correctly, you use =E2=80= =9Cdomain=E2=80=9D > if the following places where you should use =E2=80=9Czone=E2=80=9D: > > Section 2: > > However, they can be assumed to be able to provide registration > domain discovery and routing. > > Section 2.2: > > As described above, full-featured devices are responsible for knowing in > what domain they should register their services. > > In terms of DNS terminology, the correct term is domain, not zone. The registration domain doesn't have to be at a zone cut. --00000000000083db94057124756c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 8:59 AM, Tom Pusateri <pusateri@bangj.com> wrote:
The TTL addition still leaves ambig= uity for the server implementation:

"Service = Registration servers SHOULD ensure that TTLs are reasonable: neither=C2=A0t= oo long nor too short.=C2=A0 The TTL should never be longer than the lease = time.=E2=80=9D

Can you give guidance for =E2=80=9C= too short=E2=80=9D? =E2=80=9Ctoo long=E2=80=9D seems to be > lease time.= If this isn=E2=80=99t what you mean by =E2=80=9Ctoo long=E2=80=9D, guidanc= e on that would be appreciated too.

And finally, i= f the TTL is =E2=80=9Ctoo long=E2=80=9D or =E2=80=9Ctoo short=E2=80=9D, how= does the server respond? Does the server accept the registration and modif= y the TTL? Does the server reject the registration and return an error? Wha= t error code?

I've added te= xt.=C2=A0 =C2=A0The answer is that it's not an error for the SRP Update= to contain a TTL that the server doesn't like=E2=80=94if the server do= esn't like it, it just overrides it.
=C2=A0
One minor nit. If I understand the distinction correctly, you= use =E2=80=9Cdomain=E2=80=9D if the following places where you should use = =E2=80=9Czone=E2=80=9D:

Section 2:
<= br>However,=C2=A0they can be assumed to be able to provide registration dom= ain=C2=A0discovery and routing.

Section 2.2:
=

As described above, full-featured devices are responsib= le for knowing=C2=A0in what domain they should register their services.

In terms of DNS terminology, the c= orrect term is domain, not zone.=C2=A0 =C2=A0The registration domain doesn&= #39;t have to be at a zone cut.=C2=A0
--00000000000083db94057124756c-- From nobody Mon Jul 16 14:27:21 2018 Return-Path: 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 7E95D130E41 for ; Mon, 16 Jul 2018 14:27:19 -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 VmhD6xK3dwdb for ; Mon, 16 Jul 2018 14:27:17 -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 B13E3130DF4 for ; Mon, 16 Jul 2018 14:27:16 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1531776435; bh=GjqTuXQTwEbdiQvfvomnjlfDW5zjQWjf3D2bEdlNZD4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N3JocTZbnsN1m41Vsxch0f3e1bVGq7akxLNEEHqf2ydPQ6QNonpbNH6d90zp2EXcl QanTMdnIYmJufPxcKG9I159UZDT8kumHwFwxKZw89q4IfX77AxrXQgGt4Di1OfNLGe j41gWgU06rkXPksMEB589kogJWdrhHAEF11AU4IlNLSrk6pX0oiJ9SAD773t+hY3h7 OahGp1TjLzaFe3o1bi8xw6AHH3uRmm2+6NwGgZLRiQ3DfPJsmZpTAWuzMNfcei9yAk 25ANuwIRbajex+f1/kx8eY4W0XCk9RJn6VVgRZpiY8Cw5G0xuRj2I2nXK4mdd4yQVg /u5dcZiVHTEXw== To: Ted Lemon , Tim Wattenberg Cc: dnssd In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> Date: Mon, 16 Jul 2018 23:27:03 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a7qq6fdk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:27:20 -0000 Ted Lemon writes: >> - 2.4.2 (naming issue mentioned by Toke): If I understand correctly, it >> should say "A Registration MUST include at least one Service Discovery >> update, at least one Service Description update, and exactly one Host >> Description update." >> > > Yes, fixed. Why can't it be just a Host Description? Might be useful for a device that just wants to register its name but doesn't (currently, or ever) advertise any services... -Toke From nobody Mon Jul 16 14:28:52 2018 Return-Path: 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 B61801311EA for ; Mon, 16 Jul 2018 14:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 ensm0Dvbv6eU for ; Mon, 16 Jul 2018 14:28:49 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 C79FA130E41 for ; Mon, 16 Jul 2018 14:28:48 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 188-v6so23619362ita.5 for ; Mon, 16 Jul 2018 14:28:48 -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=v0gIPezkW2vtczbil/fduf/th3Io4ZCdFr1/15DWmJw=; b=SbiwGF0gkfVHIOffuV2oB3qvptXRanWWrsOHzTr9zmfZrPkJNIJ5SEcf+uHRevkD9K uZN2nl6OwF6tXyqpaDPihPVaNqRzaZacRVo7wMH6QjFeaifWEbpS8d9Ss18E+K9xjkHL 5LNxthOSvEH+dyzfkQY0ALtsBX1oBBIMgoY9vFNkwsg/5y4r1BnmzsZvpYgpxRo3F8C6 2vZSl+zI8Yh3ip+iyfLknhiUKZImuyhYTMORBgguVUeugjlOLxIjyea9/yfAku2aReio EOQa21UxyUsl+Iy2q8NHTOxhv5X4cjAvDPKaZCdU1piZE/rbV/aACBhH7AHSIhDs8e2p Inzw== 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=v0gIPezkW2vtczbil/fduf/th3Io4ZCdFr1/15DWmJw=; b=RGYGCvhFLfrNSVyMq37J5zDq0uCnlSe9mhiz3vlCDusPR55YlVptovMEcVSfdwIqTm RmsDHYuTr2K/lig5ce49VnjwlCxZ7iL7K/suUPYX2OyalAKx1yBsuKICXJ7ObiRe8AOR x+DfUJMz8kziFQoGc0f6NYv7SKiXW7qgVXZtJ7hj9TW66y6WEIqEFStvttd1vlA3azPW MiUGLR9yHi4sTSaGAUugP6lExikzkJmDOL6ET+5BjCSqWmSRm5jTccdDaBK5hefY34pX 52fKg8G/E/+jeWWBcss10gIEb+ShISHuheVhqcKAZNOej3lOhLLvn2rR8n3Ssta6V1Ys +5ww== X-Gm-Message-State: AOUpUlEsWzyQgRIwFBnnALGeRMPUwdNTUeuMigX6dFHmRRgKxY/jEE6h lkcGQzgy11+RoagEiM03UpefaeQPKhPe3UKXTc2Klw== X-Google-Smtp-Source: AAOMgpfBQLrTIYxIbo3ahaPbAkqDyZZFQnJlKWsC6zcxq0mssPgB/sOHX1GpEoAuWP2J/+cxtJTaVGfCKHxEQiTbmZo= X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr14230547itb.144.1531776528102; Mon, 16 Jul 2018 14:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:28:07 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> From: Ted Lemon Date: Mon, 16 Jul 2018 17:28:07 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000d54dcd0571248342" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:28:51 -0000 --000000000000d54dcd0571248342 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri wrote: > > May I suggest that the server adjusts the TTL to a reasonable value > (guidance) and returns the new value in the response. > I don't think this is important. What behavior on the client would change on the basis of this guidance? The client doesn't necessarily know which server it's talking to, so the advisory TTL value, if retained, might be considered wrong next time it sends an update. strations with this server. > > New Feedback > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > Section 2 says: > > 'In other network environments, updates for names ending in > "services.arpa" may be rewritten internally to names with broader > visibility.=E2=80=99 > > And Section 2.2 says: > > =E2=80=98...and let the DNS-SD Service Registration server handle rewriti= ng that > to a different domain if necessary.=E2=80=99 > > When the registration server rewrites the domain, does it send the new > domain back in the response? I couldn=E2=80=99t find that anywhere in the= document. > Does it have to send back all of the records in the request? Can it send > just a header if the Zone doesn=E2=80=99t change and the TTL doesn=E2=80= =99t change? Can it > only complete the Zone section if the zone name changes but the TTL stays > the same with nothing changes in the Update section? > We concluded that it does not. The only case where this happens now is for constrained devices, and constrained devices shouldn't care. > Section 2.3.3: > > 'To do so, it must discover default registration zone=E2=80=99 =E2=80= =94=E2=80=94> insert =E2=80=98the=E2=80=99 > thanks. > > Section 2.4.2 Page 9: > > change =E2=80=9Crejectration=E2=80=9D to =E2=80=9Cregistration=E2=80=9D. > Done. > > Throughout the document "DNS-SD Registration Protocol=E2=80=9D is used > synonymously with "DNS-SD Service Registration Protocol=E2=80=9D. If the = latter is > too many words, you might substitute =E2=80=98this specification=E2=80=99= . This becomes > even more confusing with the discussion of service registration protocols > in RFC 6763 such as: > "Service discovery requires a service registration protocol. DNS > already has one: DNS Dynamic Update.=E2=80=9D and > "This also requires some service discovery registration protocol > to be implemented and deployed for clients to register with the central > aggregation server. Virtually every company with an IP network already > runs a DNS server, and DNS already has a dynamic registration protocol.= =E2=80=9D > This provides additional motivation for a new name. > > =E2=80=9CRegistrations=E2=80=9D is capitalized lots of places where it pr= obably shouldn=E2=80=99t > be: "Ordinarily Registrations will fail=E2=80=A6=E2=80=9D > Yeah, I went through the document and noticed that there was a huge amount of inconsistent use of terminology. I updated the document to use SRP instead of the various permutations of DNS-SD Service Registration Protocol, SRP Server for the various permutations of Registration server, and SRP update instead of Registration. --000000000000d54dcd0571248342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 2:47 PM, Tom Pusateri <pusateri@bangj.com> wrote:
May I suggest that the server adju= sts the TTL to a reasonable value (guidance) and returns the new value in t= he response.

I don't think this is = important.=C2=A0 =C2=A0What behavior on the client would change on the basi= s of this guidance?=C2=A0 =C2=A0The client doesn't necessarily know whi= ch server it's talking to, so the advisory TTL value, if retained, migh= t be considered wrong next time it sends an update. strations with this ser= ver.

New Feedback
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94

Section 2 says:

'In other network environments, updates for names ending in "servi= ces.arpa" may be rewritten internally to names with broader visibility= .=E2=80=99

And Section 2.2 says:

=E2=80=98...and let the DNS-SD Service Registration server handle rewriting= that to a different domain if necessary.=E2=80=99

When the registration server rewrites the domain, does it send the new doma= in back in the response? I couldn=E2=80=99t find that anywhere in the docum= ent. Does it have to send back all of the records in the request? Can it se= nd just a header if the Zone doesn=E2=80=99t change and the TTL doesn=E2=80= =99t change? Can it only complete the Zone section if the zone name changes= but the TTL stays the same with nothing changes in the Update section?
=

We concluded that it does not.=C2=A0 =C2= =A0The only case where this happens now is for constrained devices, and con= strained devices shouldn't care.
=C2=A0
Section 2.3.3:

'To do so, it must discover default registration zone=E2=80=99=C2=A0 = =C2=A0=E2=80=94=E2=80=94> insert =E2=80=98the=E2=80=99
<= div>thanks.
=C2=A0

Section 2.4.2 Page 9:

change =E2=80=9Crejectration=E2=80=9D to =E2=80=9Cregistration=E2=80=9D.
Done.
=C2=A0

Throughout the document "DNS-SD Registration Protocol=E2=80=9D is used= synonymously with "DNS-SD Service Registration Protocol=E2=80=9D. If = the latter is too many words, you might substitute =E2=80=98this specificat= ion=E2=80=99. This becomes even more confusing with the discussion of servi= ce registration protocols in RFC 6763 such as:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Service discovery requires a service regi= stration protocol. DNS already has one: DNS Dynamic Update.=E2=80=9D and =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This also requires some service discovery= registration protocol to be implemented and deployed for clients to regist= er with the central aggregation server.=C2=A0 Virtually every company with = an IP network already runs a DNS server, and DNS already has a dynamic regi= stration protocol.=E2=80=9D
This provides additional motivation for a new name.

=E2=80=9CRegistrations=E2=80=9D is capitalized lots of places where it prob= ably shouldn=E2=80=99t be: "Ordinarily Registrations will fail=E2=80= =A6=E2=80=9D

Yeah, I went through the d= ocument and noticed that there was a huge amount of inconsistent use of ter= minology.=C2=A0 =C2=A0I updated the document to use SRP instead of the vari= ous permutations of DNS-SD Service Registration Protocol, SRP Server for th= e various permutations of Registration server, and SRP update instead of Re= gistration.=C2=A0

--000000000000d54dcd0571248342-- From nobody Mon Jul 16 14:30:26 2018 Return-Path: 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 E66DA13125C for ; Mon, 16 Jul 2018 14:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 coeECCHC1aGt for ; Mon, 16 Jul 2018 14:30:15 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 2261D131247 for ; Mon, 16 Jul 2018 14:30:13 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7-v6so39282361ioj.1 for ; Mon, 16 Jul 2018 14:30:13 -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=YyHNMTICJehYytlWe8vf/vN4AzJneZ70Rp88Rl6DbzQ=; b=AxKyHCVUQHzXMjyMywxwBm23Lf1ZbAF1Zfsq8BMTIJ3JysPdRJnXk0PQbMfE0ZMesH eFKpe9BwuI/DfyWvxmx8bfEsggMh7DWtrkNNaGcCbj/66famx22gC0KnMcLVpbVrcmv+ ddVgxwc7UgI3sHNFW/fUTPDMLTpSrWp4KAK3IKcSCnnaYLn6WaBk2TPyT7Mkq6j52c3L j6ho5iiuftZdSbv+RgzNBolnd/lhbukwlmwfDRqPG+DYwYqpnZ4oOMK1cZ7Ec6fWSJDV VOxvsTRTT3WIc3YAPV1J4YwFIpu6813O8WNfGO7gSoBUJLDmEKT8ONrAfFXv5+qtFYot B2Bg== 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=YyHNMTICJehYytlWe8vf/vN4AzJneZ70Rp88Rl6DbzQ=; b=juodebXjv4wPAdlavF5alN51C4W0CBfi7oJ1RU1GK2k1x2H/x2pqHG34lhi8zz/CHC wUeZc6QPNjW8IpqBL2dQNoQSsxiaAaztpfeeCwogrx4q7f6rcXNNgKYLOsqKvJO0x0bD c05lqdIcb6BvYwtbWY1D7e5W34qGqmHj4SLaDFB9hlDsKziOrKi1NXeL0jUGAcnus9+z 7hAO570Xek+vLomq3BG7f+4sSM3q71lwSUPOV4lpiee+TKvTiB2rW1UEksL19ARoTN6q q7OfAYR+GcozF+CEP4W6V+5eKqHEkh/hMq2CyyUzW+vnA7dPaP/9FPznNsXppdZU4oh2 DAEg== X-Gm-Message-State: APt69E0TaKt646Jys3GSKv3BIk/Q3bZaBp9QfNRLFP4R3V47/xB5jFOE oMGLElm0knA+Mu6KVV9umEnBtPBrFsWmDpPXQxE8NuAT X-Google-Smtp-Source: AAOMgpc5IFo122YIpOzVoJ7mINr7E/XMDqQSYdo9wDZxLh1WZMkWakeSqY7JyIj1OvJAYUOs0+ZUc+s2Zr6JngjDANE= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr40929962ioc.45.1531776612474; Mon, 16 Jul 2018 14:30:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:29:32 -0700 (PDT) In-Reply-To: <87a7qq6fdk.fsf@toke.dk> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> From: Ted Lemon Date: Mon, 16 Jul 2018 17:29:32 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Tim Wattenberg , dnssd Content-Type: multipart/alternative; boundary="000000000000dcb9bd05712488c0" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:30:24 -0000 --000000000000dcb9bd05712488c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > Why can't it be just a Host Description? Might be useful for a device > that just wants to register its name but doesn't (currently, or ever) > advertise any services... > > Good question. What does the working group think? :) --000000000000dcb9bd05712488c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
Ted L= emon <mellon@fugue.com> write= s:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does the working group think?=C2= =A0 =C2=A0:)=C2=A0

--000000000000dcb9bd05712488c0-- From nobody Mon Jul 16 14:47:38 2018 Return-Path: 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 7C993131224 for ; Mon, 16 Jul 2018 14:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 Fj6b2y8fHDCH for ; Mon, 16 Jul 2018 14:47:34 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 E45F413120D for ; Mon, 16 Jul 2018 14:47:33 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id l7-v6so39325168ioj.1 for ; Mon, 16 Jul 2018 14:47:33 -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=K7Pva4RCeV5wL3k8oTIGvWxyXhdusPjq0I2Ken7CDw4=; b=XQYyoOds5eA231Dn/fctwnV3/OVoNbR90GWSA0ImhBUT5MSsKHybipx+u5iUT87LuH nwVSiqfgclgQ4U6VqsxI3q3vVkEmavNp6BMjApMFwcIKrFbH+Ul0q7+sGN/N35hjmXyz 1lqfcG8f4DpnY+nLwmflQeLDVLgO3+34vx3hIUYgMnHUflKr/FPJndC05R9doQMuzJFB xDWd1tOdAR2SudgiLQ3ZnLzADVYjYTPG95n4Y612BKWdkPFAEvEZGUDXTqgNtkSIiTme tJpzP/isuTlHunoawhTdWr0bHcy46s8zviazcwRiD8szCeGImzYE4R+ZcofxwrBUwNJg mo8w== 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=K7Pva4RCeV5wL3k8oTIGvWxyXhdusPjq0I2Ken7CDw4=; b=cYPVSeOymWSc7Q0/KrCKsMj5NzdqAQJ1iuJXTkAqDqyiGNkxhzWsvRVQViYfR//8Rb 74J77/EEDo+OgqsdOn82mEJ6tOUKVdGHOHoCEfogYAhlT9ZbliBsOOptbxByOjlwof/u 8M8nLnPs0wKCfWvpqUVxNbvJNId/vy/J5kfWUqTffCGxwxkBIQBmiuGeM6ELpt8SqkQR dvyPE6NcRzcET4WsS7usCy45N56BkGrXYmpp1zJJZenM9mZb4EClyI3Q7pSGP/oWNVk5 /ppC9G+VPv8j/fJGb35FeURdDa5zZPSGpmKWcGxWmOw1D7+bJJ790gHbPZpKEp+ihFq1 ODyg== X-Gm-Message-State: AOUpUlHd1CKWup9+No4IrOz7XsNX+gXd4MjzFJPRc0fZMa32ATAMgtVf M7iJLwjGtOl33urgj6I3LQj3nNQg2lM+YrwFjJ1ri7AI X-Google-Smtp-Source: AAOMgpePP1J3p0dXC5PwVkcIkzR5UfvQZxnURv0B56UZH1i2gfXAAittM8DAaVoaXM9j+5UJMoAVhqh0XxK3aEitr3c= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr43081673ioe.85.1531777653206; Mon, 16 Jul 2018 14:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:46:52 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> From: Ted Lemon Date: Mon, 16 Jul 2018 17:46:52 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Tim Wattenberg , dnssd Content-Type: multipart/alternative; boundary="000000000000e4fa75057124c6b4" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:47:37 -0000 --000000000000e4fa75057124c6b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BTW, the current version of the document on github now includes fixes for all the points that have been raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: > On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > >> Ted Lemon writes: >> >> Why can't it be just a Host Description? Might be useful for a device >> that just wants to register its name but doesn't (currently, or ever) >> advertise any services... >> >> Good question. What does the working group think? :) > > --000000000000e4fa75057124c6b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BTW, the current version of the document on github now inc= ludes fixes for all the points that have been raised other than the ones I = said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/d= raft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@f= ugue.com> wrote:
On Mon, Jul = 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <= ;toke@toke.dk> wrote:
Ted Lem= on <mellon@fugue.c= om> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does = the working group think?=C2=A0 =C2=A0:)=C2=A0

<= /div>

--000000000000e4fa75057124c6b4-- From nobody Mon Jul 16 14:59:34 2018 Return-Path: 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 D8DFF13122A for ; Mon, 16 Jul 2018 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IbEEZk00PG0k for ; Mon, 16 Jul 2018 14:59:27 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE40131071 for ; Mon, 16 Jul 2018 14:59:25 -0700 (PDT) Received: from [31.133.144.253] (dhcp-90fd.meeting.ietf.org [31.133.144.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 7B126870; Mon, 16 Jul 2018 17:57:41 -0400 (EDT) References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-E1600458-103E-4DF8-BAE6-3DD282E0CCE1 Message-Id: Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , dnssd , Tim Wattenberg X-Mailer: iPad Mail (14G60) From: Tom Pusateri Date: Mon, 16 Jul 2018 17:59:23 -0400 To: Ted Lemon Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:59:30 -0000 --Apple-Mail-E1600458-103E-4DF8-BAE6-3DD282E0CCE1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How is DNS-Based Service Discovery different from DNS Service Discovery? Is this meant to distinguish from RFC 6763? =20 Thanks, Tom > On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >=20 > BTW, the current version of the document on github now includes fixes for a= ll the points that have been raised other than the ones I said I wasn't goin= g to fix: https://github.com/StuartCheshire/draft-sctl-service-registration >=20 >> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>=20 >>> Ted Lemon writes: >>>=20 >>> Why can't it be just a Host Description? Might be useful for a device >>> that just wants to register its name but doesn't (currently, or ever) >>> advertise any services... >>>=20 >>=20 >> Good question. What does the working group think? :)=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail-E1600458-103E-4DF8-BAE6-3DD282E0CCE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How is DNS-Based Service Discovery diffe= rent from DNS Service Discovery?

Is this meant to disti= nguish from RFC 6763?
 
Thanks,
Tom

On= Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on github now inc= ludes fixes for all the points that have been raised other than the ones I s= aid I wasn't going to fix: https://github.com/StuartCheshire/draft-sc= tl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon &= lt;mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27= PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:
Why can't it be just a Host Description? Might be useful for a de= vice
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the w= orking group think?   :) 


____________________= ___________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mai= lman/listinfo/dnssd
= --Apple-Mail-E1600458-103E-4DF8-BAE6-3DD282E0CCE1-- From nobody Mon Jul 16 15:02:40 2018 Return-Path: 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 1CD04130E00 for ; Mon, 16 Jul 2018 15:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 Iy8EUSrVCngl for ; Mon, 16 Jul 2018 15:02:31 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 93043130DF4 for ; Mon, 16 Jul 2018 15:02:31 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id v26-v6so39324547iog.5 for ; Mon, 16 Jul 2018 15:02:31 -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=IcW3b4ITllAYeuiivO3d9J4vAhEMF7ChAv6V9OMxKDE=; b=AXEUiOKSi4qzyJvAMhIPB586acsXMWIj17Mt0hiRSRy8n9k//rAPexxKh/WMMwZvvF nMB+1/1iWzi+qSBsF4QqEwLWsmdKXkOnA+zYs8Ni8P/DPWj4EqXtbTkliWOHoVssDKMh Hli0WP5X+9lMeTveWYqGihOhcjnN+HQ42QF2Va+xq74+lerAFm5lON3P3d7V1V1MGsIE fNznIg6jfVKnhZEtSkTr8429mhSWMHoCMS7/hH4r1YYyYCXhe8OvYsEHDUqKhAJVRCxu EdQmjgwbAW9PyDKgM0S6Zy7aSb+WjVQcl5uYl1y5QYRw5h0X0pdv2YZqy/oHQFMyXKZv Z6ug== 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=IcW3b4ITllAYeuiivO3d9J4vAhEMF7ChAv6V9OMxKDE=; b=ogbNmSjgJoDOmkkEMhETP+JCZOy5pALL5ZQNeaHMg6/LdS14kKyt08e/0bH2enCGqq Gd5VzNtO28y5UiG1+lC5OGbiqtbizhwiQVUIo5inPsB7jV/nHb9swIHiLj8fCbk6tkaf bfAIcPaZ1lErNF/C+i4vzPdE1vIaUQrzjqNacHzmLZf+vkE4V3OY5YO6IlUafqujuC5c OozrYAjSRmXp6fFGDqzLADl+ENCeogb8IUtbyIZuZgVSPyiQUM8jSuIrWRfDnP8JQp7i Ei2yFhJsgVUvQNlURhXKiFg5tzHSeIZh4URsJn0g+5YRT/o/uvRLZELpaEGS8vqa7wqq fM0g== X-Gm-Message-State: AOUpUlF1YV6QpH9om5VvO+LniGpm+TMHg6qYwZBo+aOnVD5lFWkAzBmU i3HsKamKj2dBR9SN8hp/sniB/cEUEmOD7hObeQGGrQ== X-Google-Smtp-Source: AAOMgpddh6suJI9KCe7/0VSTgvVdL3lFXkLIzp7Fujfs1NGGU4ymg8N8kSvql7smjMbsVQegiFLfkiATwur8JYTmUxo= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr1520856ioe.32.1531778550904; Mon, 16 Jul 2018 15:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 15:01:50 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> From: Ted Lemon Date: Mon, 16 Jul 2018 18:01:50 -0400 Message-ID: To: Tom Pusateri Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , dnssd , Tim Wattenberg Content-Type: multipart/alternative; boundary="00000000000066d5da057124fc5a" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:02:36 -0000 --00000000000066d5da057124fc5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The title of RFC 6763 is DNS-Based Service Discovery. So I tried to harmonize the document toward that=E2=80=94did I miss something? On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote: > How is DNS-Based Service Discovery different from DNS Service Discovery? > > Is this meant to distinguish from RFC 6763? > > Thanks, > Tom > > On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: > > BTW, the current version of the document on github now includes fixes for > all the points that have been raised other than the ones I said I wasn't > going to fix: https://github.com/StuartCheshire/draft-sctl- > service-registration > > On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: > >> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >> wrote: >> >>> Ted Lemon writes: >>> >>> Why can't it be just a Host Description? Might be useful for a device >>> that just wants to register its name but doesn't (currently, or ever) >>> advertise any services... >>> >>> Good question. What does the working group think? :) >> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --00000000000066d5da057124fc5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The title of RFC 6763 is DNS-Based Service Discovery.=C2= =A0 =C2=A0So I tried to harmonize the document toward that=E2=80=94did I mi= ss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com&g= t; wrote:
<= /div>
How is=C2=A0= DNS-Based Service Discovery different from DNS Service Discovery?

Is this meant to distinguish from RFC 6763?
=C2=A0
<= div>Thanks,
= Tom

On Jul 16, 2018, at 5:46 PM= , Ted Lemon <mello= n@fugue.com> wrote:

BTW, the current version of the document on github now include= s fixes for all the points that have been raised other than the ones I said= I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:2= 9 PM, Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgense= n <t= oke@toke.dk> wrote:
<= span>Ted Lemon <me= llon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.= =C2=A0 =C2=A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0=


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

--00000000000066d5da057124fc5a-- From nobody Mon Jul 16 15:41:33 2018 Return-Path: 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 277D6131242 for ; Mon, 16 Jul 2018 15:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cnwzWSXaHVOo for ; Mon, 16 Jul 2018 15:41:28 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9E8128BAC for ; Mon, 16 Jul 2018 15:41:28 -0700 (PDT) Received: from [192.168.1.12] (modemcable091.29-131-66.mc.videotron.ca [66.131.29.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 6857087D; Mon, 16 Jul 2018 18:39:43 -0400 (EDT) From: Tom Pusateri Message-Id: <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A0D784C6-8A40-4E48-9673-4502D9EC0C04" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 16 Jul 2018 18:41:25 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:41:31 -0000 --Apple-Mail=_A0D784C6-8A40-4E48-9673-4502D9EC0C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok, just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763? Thanks, Tom > On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >=20 > The title of RFC 6763 is DNS-Based Service Discovery. So I tried to = harmonize the document toward that=E2=80=94did I miss something? >=20 > On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: > How is DNS-Based Service Discovery different from DNS Service = Discovery? >=20 > Is this meant to distinguish from RFC 6763? > =20 > Thanks, > Tom >=20 > On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >=20 >> BTW, the current version of the document on github now includes fixes = for all the points that have been raised other than the ones I said I = wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>=20 >> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >> Ted Lemon > writes: >>=20 >> Why can't it be just a Host Description? Might be useful for a device >> that just wants to register its name but doesn't (currently, or ever) >> advertise any services... >>=20 >> Good question. What does the working group think? :)=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_A0D784C6-8A40-4E48-9673-4502D9EC0C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok, = just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul = 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery.  =  So I tried to harmonize the document toward that=E2=80=94did I = miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on = github now includes fixes for all the points that have been raised other = than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_A0D784C6-8A40-4E48-9673-4502D9EC0C04-- From nobody Mon Jul 16 15:43:28 2018 Return-Path: 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 98AF5130E98 for ; Mon, 16 Jul 2018 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 awnIpLzRAMTA for ; Mon, 16 Jul 2018 15:43:17 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 233B813125C for ; Mon, 16 Jul 2018 15:43:17 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id v71-v6so23888171itb.3 for ; Mon, 16 Jul 2018 15:43:17 -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=OzQ4H42XPbdF7YlrA2HDZkGx/82JX6rMNcQGZxgLIns=; b=UmqiG0FDI+2efXnop+fAbz4BPelZ8G3PW0VOYTZfP7FPUE/N4vdN5yxjyiNC6+Uuw9 JFKIz8jfQMT8Lm87PuoPNCEI+woTD/dsI+SVKy3Eh3prz0j7R9XbYFdCym1w39tsYGWj XXQ0uM4Ov8dD+BiNgqJTe7viyUPjweMu/W5Ztn1ptDdB8YDrPW7VPa4ECdaAcIsQErra ZecxHPjMGTOkLn5g/XRtKKsbVtVwCqLQ+yBYMh6uZIhMg2vk0VHA7CQtqwHozxUg/Vjb mmKBnYVdmlqNf/gjLPx7MZQC+dTgPwZo0IM4o02Ys3HN8+d18RQ9FStGAJRELpVGjtV9 RGlg== 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=OzQ4H42XPbdF7YlrA2HDZkGx/82JX6rMNcQGZxgLIns=; b=mkVCK21Y5CtKirG5Tr/Lkdfl/u+oierTh3XtKlDf2W1qjQDWicETzU2rq4zgasd8TZ QweBoBA1EEw0FZ6Eiz7H+SsEnq9B5ufMWDIcA9OnzdBY9PXTyueeggQzuvRiTZTAmykQ sakOX2YsfKBDY36m0TbDfwIcZyE6i9RIBZKmeRcFWc9BNT6F8J7X2uzQPaIxV0btDzv4 9gHiiHFP2QYV/yABz3rRM6N6xSeTpdG24YjPDaAYo0xpqpe3WobAqK3YpGhYH3u66TIq L3GS2zXycSuUxgSjt7sJ86n/LJ12OsCuxte+kFOERGePuJpqGuNao1Ti/oPXottVnOlR 9nwA== X-Gm-Message-State: AOUpUlFWtZVUf2zODMBAThTG8W4q3O/o4eyByB84iWybgYMtVujBKqqc kDKfiLLPCI/VXeKkoC2sZP97yxk5zDeyYDgmUsxpEQ== X-Google-Smtp-Source: AAOMgpdymCHxfJ339IDeEBCyhEIWvaRsd9iXgYNBcjG956lGUTHfI5i/2yU1BV1XiNC0gg1J6vINMYaT6veKqWFzaFs= X-Received: by 2002:a24:f509:: with SMTP id k9-v6mr14506963ith.98.1531780996473; Mon, 16 Jul 2018 15:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 15:42:36 -0700 (PDT) In-Reply-To: <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> From: Ted Lemon Date: Mon, 16 Jul 2018 18:42:36 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000002b41420571258e07" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 22:43:22 -0000 --0000000000002b41420571258e07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The question of whether we update RFC6763 is basically "is there text that is in RFC6763 that is no longer correct because of this document." I think the answer is no. On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote: > Ok, just checking. So given that 6763 semi-defines service registration > protocol as DNS Dynamic Update, should this document claim it updates 676= 3? > > Thanks, > Tom > > On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: > > The title of RFC 6763 is DNS-Based Service Discovery. So I tried to > harmonize the document toward that=E2=80=94did I miss something? > > On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote: > >> How is DNS-Based Service Discovery different from DNS Service Discovery? >> >> Is this meant to distinguish from RFC 6763? >> >> Thanks, >> Tom >> >> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >> >> BTW, the current version of the document on github now includes fixes fo= r >> all the points that have been raised other than the ones I said I wasn't >> going to fix: https://github.com/StuartCheshire/draft-sctl-service- >> registration >> >> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >> >>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>> wrote: >>> >>>> Ted Lemon writes: >>>> >>>> Why can't it be just a Host Description? Might be useful for a device >>>> that just wants to register its name but doesn't (currently, or ever) >>>> advertise any services... >>>> >>>> Good question. What does the working group think? :) >>> >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --0000000000002b41420571258e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The question of whether we update RFC6763 is basically &qu= ot;is there text that is in RFC6763 that is no longer correct because of th= is document."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom= Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service registration= protocol as DNS Dynamic Update, should this document claim it updates 6763= ?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted L= emon <mellon@fugue= .com> wrote:

The title of RFC 6763 is DNS-Based Servic= e Discovery.=C2=A0 =C2=A0So I tried to harmonize the document toward that= =E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusate= ri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery different from DNS Service Di= scovery?

Is this meant to distinguish from RFC 6763?
=
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

<= /div>
BTW, the current versi= on of the document on github now includes fixes for all the points that hav= e been raised other than the ones I said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-servic= e-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon &l= t;mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5= :27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

=
Good question.=C2=A0 =C2=A0What does the working group think?=C2=A0 = =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd


--0000000000002b41420571258e07-- From nobody Tue Jul 17 07:03:40 2018 Return-Path: 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 ABBCE130E3D for ; Tue, 17 Jul 2018 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MwblGqLUYVpo for ; Tue, 17 Jul 2018 07:03:30 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 91957130F5C for ; Tue, 17 Jul 2018 07:03:29 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id r16-v6so1383844wrt.11 for ; Tue, 17 Jul 2018 07:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XOXZerQKG2xjHFt/e/+nf1Dka71bPQoVrpj6howuI98=; b=mOYqruy9JDozxJRADsTAYlacgdOOhaIi6hhvMnFMjsdSUtae1+3wxRwQhluTsoj1SR zLCn6JfZrCmZXIqluSXt9qS3nqYHTp/PK+ceRn7OixTXphyf/ueGbDEBfixhrFpljBJS 0vcL+y45SofdIAipdRI+XcisygqZKd2AxPYDUgmFu9H6NLQCoBIG0prjwIQCjnjekphO WEL8ZPEP/6Mi00xn0AscXKrcNiOWF397hKBj5ixThEjQZmYn8kkCgWmkS/1laylz+1uB zoUPp/8AfQoixE6gfaCqfhxJ16XKItHS17/Ituz+8T02nwOEi4v7T24+fGP30PaMK/Ks 8EuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XOXZerQKG2xjHFt/e/+nf1Dka71bPQoVrpj6howuI98=; b=g//lKnFxkVeqnzZ1kEqRNYIBY8nn9U0ahEYTwe8f7Re6UnmMizxRlhWjt/nEqnUUs2 W99ksThBg5Z0xb4eXbvZH3sFKYN/59nDXljBSZ3LgIfl1YjefM7KaFyZBnBbPHY61wMC c5Ez4Bla7SmzzW81WQt66ZtD+jha7unk2nEpzksTj8VNthO3gtZR8Tu6Oww4bjir4xQX cY34y6k93OGfj7CKdAB79LoUY8ALoJOOkXjDO0e0MzWSqPc+Kfg/oLChGL8+Y2RW0SvS YSzcIBVuMCsdzO8A/I2wnJL8bi1yzDpT9S8zcyAAGfA4E6P6M/MKapGiXEfw6a4tBa7a jHVg== X-Gm-Message-State: AOUpUlHKPDwYvvj6eEP/8g27TGnKifCG+f5t97lTjS8Sb960pFDvzobB +tx6USu/36gHSDlnsqWFgzNMCuQgoEjmJuvrvso= X-Google-Smtp-Source: AAOMgpckeM5vyp+5ldf5Pxi1bwv1JPVw4a4tDZ8XA7ogWlzBd9qcByJEYnfW9jkKUMtNKHGLettwI9XODE/od5JAUzg= X-Received: by 2002:adf:f001:: with SMTP id j1-v6mr1448742wro.260.1531836208076; Tue, 17 Jul 2018 07:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 07:03:27 -0700 (PDT) From: Tim Wicinski Date: Tue, 17 Jul 2018 10:03:27 -0400 Message-ID: To: dnssd@ietf.org Cc: "" Content-Type: multipart/alternative; boundary="000000000000095b87057132691e" Archived-At: Subject: [dnssd] DNS-SD minute takers and jabber scribes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:03:37 -0000 --000000000000095b87057132691e Content-Type: text/plain; charset="UTF-8" All, I'm assisting David with the details of the DNSSD meeting on Thursday (as well as filling in the necessary Tim requirement). We're looking for minute takers and a jabber scribe or two. Thanks all. Tim (the other one) --000000000000095b87057132691e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,=C2=A0

I'm assis= ting David with the details of the DNSSD meeting on Thursday (as well as fi= lling in the necessary Tim requirement). =C2=A0 We're looking for minut= e takers and a jabber scribe or two.=C2=A0

Thanks = all.=C2=A0

Tim
(the other one)
--000000000000095b87057132691e-- From nobody Tue Jul 17 13:13:32 2018 Return-Path: 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 06935130DE2 for ; Tue, 17 Jul 2018 13:13:30 -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 7f513bCTDD0Z for ; Tue, 17 Jul 2018 13:13:25 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 8380712785F for ; Tue, 17 Jul 2018 13:13:25 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id s7-v6so934458itb.4 for ; Tue, 17 Jul 2018 13:13:25 -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=yaYwJkunJyrNzCeSotR2urqvDzQ4NEn0ytckaG7zqSI=; b=Hs/5vC3Jc23VBzSloj84x5Y09egxQuw69GsRaa+Sqia94zo/bNvikySLRReQi3KiiC tB121vGoimnWzDfi3bvDNcd4YPTXUBnsZDSTV7LRHbDI3ZaREBliqnRelilbG+fV9OV5 KWiazYFAUcvJLk/E9y+I5CAQ3iaGWCCa2ixLkm91kBrwnzjjYbrrqirmhGkLrYtqwWd6 PUj8NQ+/zVbf5Bsre/Mkazof9wsv7hjxjku/+gq3e/dEG9MaZOqLKWyHFIzt+JLK36k/ xBXsVq3WngxpfmsZRc+CUJb3gI9OgziEAivItfq7xDGN1kGr9fTw+uhSqfsJx3t/OGau rvbQ== 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=yaYwJkunJyrNzCeSotR2urqvDzQ4NEn0ytckaG7zqSI=; b=Tx6nzaoyDhl6iKnF3420WIfyFjj8y6bQjr0SrUwNAj5LdnpXAbEp5NhVtYKs/l1fN4 UR6sSyQ2W9rQr2pL3eAn4a71DXj1W+BG3g1VUBVNOt5cT7FLdLOttO6B7ie0bv1e/MLV 00UFFHdfanTOpOPvEsRTiWDVlMiQgDj3Qn/kKjDYsbICb6OqBZFxiC1MS6BUtWmgd5bM 7xHn7oo0TYKwE9/fAltyjahG3ilwKGbBGEvoVkQ30Hr6q7sBnNdjbOYMCgOOMr/LUqRh fAZrwYZNi7YQQG3LYvaI/8A5Q7NOU6csCFzKXqptCy/YcKkOkTYooNIH/U4i69RhluCb 4Bag== X-Gm-Message-State: AOUpUlGhUm7MnFKrzM1G3j87J7nuQHm8T7u/Jjw2dxeUsJRDfpK/c8+c aFGwH3+mA19YkfcXoAFyY2xF8RqLijnvrAoQ2V9wjO3l X-Google-Smtp-Source: AAOMgpeIm2dU8RZ9J8YryW0LW1+MPwbJBd48+IsIUUzs5a2p1QvxMZYhD7bDqPPpRaUwrFTWZqYxtJweBbVLly1Sibo= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr2965792itg.82.1531858404864; Tue, 17 Jul 2018 13:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:12:44 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> From: Ted Lemon Date: Tue, 17 Jul 2018 16:12:44 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000118d3f0571379453" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:13:30 -0000 --000000000000118d3f0571379453 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim pointed out that we need to protect the Service Instance Name as well as the Host Description with a KEY record, because FCFS naming has to protect both the service description and the host description. Here are the changes: https://github.com/StuartCheshire/draft-sctl-service-registration/compare/a= e53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da8= 5874597 On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: > The question of whether we update RFC6763 is basically "is there text tha= t > is in RFC6763 that is no longer correct because of this document." I thi= nk > the answer is no. > > On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote: > >> Ok, just checking. So given that 6763 semi-defines service registration >> protocol as DNS Dynamic Update, should this document claim it updates 67= 63? >> >> Thanks, >> Tom >> >> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >> >> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >> harmonize the document toward that=E2=80=94did I miss something? >> >> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote= : >> >>> How is DNS-Based Service Discovery different from DNS Service Discovery= ? >>> >>> Is this meant to distinguish from RFC 6763? >>> >>> Thanks, >>> Tom >>> >>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>> >>> BTW, the current version of the document on github now includes fixes >>> for all the points that have been raised other than the ones I said I >>> wasn't going to fix: https://github.com/Stuart >>> Cheshire/draft-sctl-service-registration >>> >>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>> >>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>>> wrote: >>>> >>>>> Ted Lemon writes: >>>>> >>>>> Why can't it be just a Host Description? Might be useful for a device >>>>> that just wants to register its name but doesn't (currently, or ever) >>>>> advertise any services... >>>>> >>>>> Good question. What does the working group think? :) >>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> > --000000000000118d3f0571379453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tim pointed out that we need to protect the Service Instan= ce Name as well as the Host Description with a KEY record, because FCFS nam= ing has to protect both the service description and the host description.= =C2=A0 =C2=A0Here are the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <<= a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@fugue.com&g= t; wrote:
The que= stion of whether we update RFC6763 is basically "is there text that is= in RFC6763 that is no longer correct because of this document."=C2=A0= I think the answer is no.

On Mon, Jul 16, 2018= at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines servi= ce registration protocol as DNS Dynamic Update, should this document claim = it updates 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery.=C2= =A0 =C2=A0So I tried to harmonize the document toward that=E2=80=94did I mi= ss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com&g= t; wrote:
<= /div>
How is=C2=A0= DNS-Based Service Discovery different from DNS Service Discovery?

Is this meant to distinguish from RFC 6763?
=C2=A0
<= div>Thanks,
= Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:
<= br>
BTW, the current v= ersion of the document on github now includes fixes for all the points that= have been raised other than the ones I said I wasn't going to fix:=C2= =A0https://github.com/StuartCheshire/draft-sctl-s= ervice-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.c= om> wrote:
On Mon, Jul 16, 2018= at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrot= e:
Ted Lemon <mellon@fugue.com> writes:<= br>
Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does the worki= ng group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



--000000000000118d3f0571379453-- From nobody Tue Jul 17 13:15:28 2018 Return-Path: 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 014C212785F for ; Tue, 17 Jul 2018 13:15:26 -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 tMsp1jVnLSon for ; Tue, 17 Jul 2018 13:15:21 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 4CC31130DE2 for ; Tue, 17 Jul 2018 13:15:21 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p17-v6so980957itc.2 for ; Tue, 17 Jul 2018 13:15:21 -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=y1fKMLbvL0L34a2J0JYrzuSNNYJcUd8xfcfMibDnqbI=; b=kdBqvtSwHp2dSFKRHClq94WKBW/XuNWeZC8Tk3MsF+dPy6y8fRw+vaOKB1jiI22IAb l/siCxTtIFGiTYj4F3h1u2D1kvkOeZ5Qjhb7QfympwRHz3niIV602JWuSb7dx+hRFZYJ t/YWPsYQJZWXRQGTI2fMk91Xtpjun0BOYidbwDSNYu/nXylvHvlXmAzaWKVHYHZS0oJj K5Uc1DhJT/IAdxnkylF5mqaVjBNsbcvnn0KQnxfQ6Roc0PNafFt/N4jAWxb7vBLVqiUS x9oeOlGAB9afP9DBNd3qCEfQSRccPZ4W5CyZX+Ex2eCagLvw5ZKAHS7FhCVmU9+FgIgm v77w== 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=y1fKMLbvL0L34a2J0JYrzuSNNYJcUd8xfcfMibDnqbI=; b=Or9aVQ0xqZkLDygi5xiyaxNmMgAHiYaI1Q6Ma8DknbxfGS93vSPQfxvPujUjtVnNAt 9ng40NPwcmAeXTL6kYEyoHkwEnLxtsJgGzkbLToyXGcSvZsj5sRe2YHf8RoFsZGKl0Qi 0kvwG9RRWjdVFjYoHv1IV3DReQ+MU1AgWTpiz8Pz20YHytYpsIwpTR8W/XDWUyzAiGu8 m7w0kryj4XCPSdmVVsHkICgVGwzVY0OOte9GBZkIgYDtJOB9+jwN97UiIK8JuR3ElefC XTexL+OoU412SRqrVTsIyLjk+T90fa0cTN55TPKvC9+EOLhT5Yq9SJEhN5nx6lhbPqeR sQpA== X-Gm-Message-State: AOUpUlFek5SLAiuh4WECH+igGlHyoRN0gML6MJ1rI1unbm3rDG1oqyiB uzP7DFtTMcPMNUF29uap07F8mGiBGk27QYQ2GvJgOg== X-Google-Smtp-Source: AAOMgpcaLWyzQ56IytJWWc8EE24qQ6YEH103PjfUUNhMrC0H5c/pYoV/6EPLS1CE8AKT+ySBToMsQvFbYnVHHfA5myA= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr2805851jad.38.1531858520672; Tue, 17 Jul 2018 13:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:14:39 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> From: Ted Lemon Date: Tue, 17 Jul 2018 16:14:39 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000f8a2c90571379ab0" Archived-At: Subject: Re: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:15:26 -0000 --000000000000f8a2c90571379ab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, this also adds text to the server behavior that simply requires that the server check the validity of the SRP Update as a DNS uipdate as well as an SRP update, since SRP update semantics are layered on top of DNS update semantics. On Tue, Jul 17, 2018 at 4:12 PM, Ted Lemon wrote: > Tim pointed out that we need to protect the Service Instance Name as well > as the Host Description with a KEY record, because FCFS naming has to > protect both the service description and the host description. Here are > the changes: > > https://github.com/StuartCheshire/draft-sctl-service-registration/compare= / > ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8 > da85874597 > > On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: > >> The question of whether we update RFC6763 is basically "is there text >> that is in RFC6763 that is no longer correct because of this document." = I >> think the answer is no. >> >> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote= : >> >>> Ok, just checking. So given that 6763 semi-defines service registration >>> protocol as DNS Dynamic Update, should this document claim it updates 6= 763? >>> >>> Thanks, >>> Tom >>> >>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>> >>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >>> harmonize the document toward that=E2=80=94did I miss something? >>> >>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>> wrote: >>> >>>> How is DNS-Based Service Discovery different from DNS Service >>>> Discovery? >>>> >>>> Is this meant to distinguish from RFC 6763? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>> >>>> BTW, the current version of the document on github now includes fixes >>>> for all the points that have been raised other than the ones I said I >>>> wasn't going to fix: https://github.com/Stuart >>>> Cheshire/draft-sctl-service-registration >>>> >>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>> >>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>>>> wrote: >>>>> >>>>>> Ted Lemon writes: >>>>>> >>>>>> Why can't it be just a Host Description? Might be useful for a devic= e >>>>>> that just wants to register its name but doesn't (currently, or ever= ) >>>>>> advertise any services... >>>>>> >>>>>> Good question. What does the working group think? :) >>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >> > --000000000000f8a2c90571379ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, this also adds text to the server behavior that simply= requires that the server check the validity of the SRP Update as a DNS uip= date as well as an SRP update, since SRP update semantics are layered on to= p of DNS update semantics.

On Tue, Jul 17, 2018 at 4:12 PM, Ted Lemon <mellon@fugue.c= om> wrote:
Tim pointed out that we need to protect the Service Instance Name as well = as the Host Description with a KEY record, because FCFS naming has to prote= ct both the service description and the host description.=C2=A0 =C2=A0Here = are the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question= of whether we update RFC6763 is basically "is there text that is in R= FC6763 that is no longer correct because of this document."=C2=A0 I th= ink the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@= bangj.com> wrote:
Ok, just checking.= So given that 6763 semi-defines service registration protocol as DNS Dynam= ic Update, should this document claim it updates 6763?

T= hanks,
Tom

On Jul 16, 20= 18, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery= .=C2=A0 =C2=A0So I tried to harmonize the document toward that=E2=80=94did = I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <<= a href=3D"mailto:pusateri@bangj.com" target=3D"_blank">pusateri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery different from DNS Service Discovery?

Is this meant to distinguish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted = Lemon <mellon@fugu= e.com> wrote:

BTW, the current version of the document on github now includes fi= xes for all the points that have been raised other than the ones I said I w= asn't going to fix:=C2=A0https://github.com/Stuart= Cheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM,= Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t= oke.dk> wrote:
= Ted Lemon <mellon@= fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2= =A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd




--000000000000f8a2c90571379ab0-- From nobody Wed Jul 18 09:05:33 2018 Return-Path: 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 BDB53130DFE for ; Wed, 18 Jul 2018 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Plt3QzIG96qt for ; Wed, 18 Jul 2018 09:05:28 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92BA124C04 for ; Wed, 18 Jul 2018 09:05:27 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3F5E9BA0; Wed, 18 Jul 2018 12:03:37 -0400 (EDT) From: Tom Pusateri Message-Id: <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF17C094-357A-417E-B0D0-621EDDB75C1E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 12:05:25 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:05:31 -0000 --Apple-Mail=_BF17C094-357A-417E-B0D0-621EDDB75C1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP. The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. Thanks, Tom > On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >=20 > Tim pointed out that we need to protect the Service Instance Name as = well as the Host Description with a KEY record, because FCFS naming has = to protect both the service description and the host description. Here = are the changes: >=20 > = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >=20 > On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: > The question of whether we update RFC6763 is basically "is there text = that is in RFC6763 that is no longer correct because of this document." = I think the answer is no. >=20 > On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: > Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >=20 > Thanks, > Tom >=20 >> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>=20 >> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to = harmonize the document toward that=E2=80=94did I miss something? >>=20 >> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: >> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>=20 >> Is this meant to distinguish from RFC 6763? >> =20 >> Thanks, >> Tom >>=20 >> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>=20 >>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>=20 >>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>> Ted Lemon > writes: >>>=20 >>> Why can't it be just a Host Description? Might be useful for a = device >>> that just wants to register its name but doesn't (currently, or = ever) >>> advertise any services... >>>=20 >>> Good question. What does the working group think? :)=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_BF17C094-357A-417E-B0D0-621EDDB75C1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be = able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> = wrote:

Tim pointed out that we need to protect the = Service Instance Name as well as the Host Description with a KEY record, = because FCFS naming has to protect both the service description and the = host description.   Here are the changes:

https://github.com/StuartCheshire/draft-sctl-service-registrati= on/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d= 544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul = 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 = is DNS-Based Service Discovery.   So I tried to harmonize the = document toward that=E2=80=94did I miss something?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on = github now includes fixes for all the points that have been raised other = than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_BF17C094-357A-417E-B0D0-621EDDB75C1E-- From nobody Wed Jul 18 09:14:23 2018 Return-Path: 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 A682F130F67 for ; Wed, 18 Jul 2018 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=timwattenberg-de.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 Sz5BwomOCkB2 for ; Wed, 18 Jul 2018 09:14:18 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 9C3F6130F17 for ; Wed, 18 Jul 2018 09:14:17 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s16-v6so4716647edq.12 for ; Wed, 18 Jul 2018 09:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timwattenberg-de.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s4VJ/xWTAlnBiQZFmdXCLNHo52HE4TAvTuagBHVa2ws=; b=P5iUpGyH9Eq1T6GT0H94uoDO70Uohg0Ol0npgtbtrJLRDMvo4iYOlpYKKXGqOXJWeb GlQn3h7gq3nb4dqAWXrgyyVyy256bASZtJGRcMvCEBBDtfELrq/aKPxknEeoK3leZ2Bu ZF5BdIBUKgBpZHSnR/71NT5GH00XilDBEJEclWc651bC7AHoNvfavWB5y/6A5+NJixXO PHPyBT2QJbfN223szX010JvY+8VC1SCeSq8YzXBiS/wsrliHU+aqbm4hrwbwF2Y4cXy0 5bS3SW1VPJb0iSlQvLnweSi1fRdiTeE151JZ1+vOUw7iJqBwjcyKFriP0OT1k1o45YsS hTVg== 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=s4VJ/xWTAlnBiQZFmdXCLNHo52HE4TAvTuagBHVa2ws=; b=WH5EoHwayeYAVOsI+JnU8BiXJi2w+xN3yXPHkUyxPAKNEifQ9BNAOpYPAVikAnM7fs xN2VLxV48+Iq2NgwxRZxFQ39mXHAuQ0FbcGujtPQCpsKuW5iOjh3nnps8YMXRw7r0UWe J1x1Tts/weVj7QYFCMyqWWScZ0nnQktu+YOryUjmS5OoTBxYbOMnQdd2lspeKCwG9t0J EgmMTmqUCPdXIiOObyJY8/MN321kuvgaNA6GG3Z1nGYPlx4SDNT2lwsyQYSv85s6tAhp ZA/7E0BUEJhM/W5O5yj9xw1B4NVS4EdNnFZ0iLVOIElWPvqbwVGSkiLP6CpkyPMjMFRi zsrQ== X-Gm-Message-State: AOUpUlGtetZK4w3HyoSm6ZbaZjwoRjc1yiexRn/mged8ukRtbPDCQDb6 XH/xWZkwWXD7K4BQA9YyTVw2q8MEDCJi1U+hbChugv6iL/U= X-Google-Smtp-Source: AAOMgpfbUgL7+EhBH6he9wv9sb3KE5XMzdf1Ei4UIZW+VOw0PqOEVTh/R2mmfq/D9OSn9m09taVyO85wHmziFBg/0GE= X-Received: by 2002:a50:a846:: with SMTP id j64-v6mr7748764edc.210.1531930456135; Wed, 18 Jul 2018 09:14:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8266:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 09:14:15 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:e4f0:45b9:44f8:16a6] In-Reply-To: <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> From: Tim Wattenberg Date: Wed, 18 Jul 2018 18:14:15 +0200 Message-ID: To: Tom Pusateri Cc: Ted Lemon , dnssd Content-Type: multipart/alternative; boundary="000000000000a8a82b0571485a68" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:14:22 -0000 --000000000000a8a82b0571485a68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, the draft references to use regular DNS update messages as of RFC 2136 -- sec. 2.1 says to use UDP if it fits and switch to TCP otherwise. However I agree that the "search domain" (dr._dns-sd._udp and _dns-update._udp) mentioning UDP might me confusing. Tim Tim Wattenberg mail@timwattenberg.de +49 1578 8248731 2018-07-18 18:05 GMT+02:00 Tom Pusateri : > If you are adding more KEY records, you will certainly exceed the UDP > update size of 512 bytes. The draft doesn=E2=80=99t mention transport but= maybe > this should be restricted to TCP. > The draft does mention searching for the update server using > _dns-update._udp.. But then it won=E2=80=99t be able to use UDP f= or > updates. > > Thanks, > Tom > > On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: > > Tim pointed out that we need to protect the Service Instance Name as well > as the Host Description with a KEY record, because FCFS naming has to > protect both the service description and the host description. Here are > the changes: > > https://github.com/StuartCheshire/draft-sctl-service-registration/compare= / > ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8 > da85874597 > > On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: > >> The question of whether we update RFC6763 is basically "is there text >> that is in RFC6763 that is no longer correct because of this document." = I >> think the answer is no. >> >> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote= : >> >>> Ok, just checking. So given that 6763 semi-defines service registration >>> protocol as DNS Dynamic Update, should this document claim it updates 6= 763? >>> >>> Thanks, >>> Tom >>> >>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>> >>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >>> harmonize the document toward that=E2=80=94did I miss something? >>> >>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>> wrote: >>> >>>> How is DNS-Based Service Discovery different from DNS Service >>>> Discovery? >>>> >>>> Is this meant to distinguish from RFC 6763? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>> >>>> BTW, the current version of the document on github now includes fixes >>>> for all the points that have been raised other than the ones I said I >>>> wasn't going to fix: https://github.com/Stuart >>>> Cheshire/draft-sctl-service-registration >>>> >>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>> >>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>>>> wrote: >>>>> >>>>>> Ted Lemon writes: >>>>>> >>>>>> Why can't it be just a Host Description? Might be useful for a devic= e >>>>>> that just wants to register its name but doesn't (currently, or ever= ) >>>>>> advertise any services... >>>>>> >>>>>> Good question. What does the working group think? :) >>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --000000000000a8a82b0571485a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, the draft references to use regular DNS update = messages as of RFC 2136 -- sec. 2.1 says to use UDP if it fits and switch t= o TCP otherwise.
However I agree that the "search domain&quo= t; (dr._dns-sd._udp and _dns-update._udp) mentioning UDP might me confusing= .

Tim
Tim W= attenberg
+49 1578 8248731

2018-07-18 18:05 GMT+02:00 Tom Pusateri <p= usateri@bangj.com>:
If you are adding= more KEY records, you will certainly exceed the UDP update size of 512 byt= es. The draft doesn=E2=80=99t mention transport but maybe this should be re= stricted to TCP.
The draft does mention searching for the update server= using=C2=A0_dns-update._udp.<= domain>. But then it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:=

Tim pointed out that we need to protect the Service Instance = Name as well as the Host Description with a KEY record, because FCFS naming= has to protect both the service description and the host description.=C2= =A0 =C2=A0Here are the changes:


On Mon, Jul 16, 2018 = at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update = RFC6763 is basically "is there text that is in RFC6763 that is no long= er correct because of this document."=C2=A0 I think the answer is no.<= /div>

On Mo= n, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 = semi-defines service registration protocol as DNS Dynamic Update, should th= is document claim it updates 6763?

Thanks,
Tom=

On Jul 16, 2018, at 6:01 PM, Ted = Lemon <mellon@fugu= e.com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery.=C2=A0 =C2=A0So I t= ried to harmonize the document toward that=E2=80=94did I miss something?

On Mon, Jul 16= , 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:=
How= is=C2=A0DNS-Based Ser= vice Discovery different from DNS Service Discovery?

Is th= is meant to distinguish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wro= te:

BTW, the c= urrent version of the document on github now includes fixes for all the poi= nts that have been raised other than the ones I said I wasn't going to = fix:=C2=A0https://github.com/StuartCheshire/draft= -sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@= fugue.com> wrote:
On Mon, Ju= l 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen &= lt;toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com>= ; writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2= =A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd


_______________________________= ________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--000000000000a8a82b0571485a68-- From nobody Wed Jul 18 09:15:13 2018 Return-Path: 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 921D6130F17 for ; Wed, 18 Jul 2018 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3CHO-31NcvBz for ; Wed, 18 Jul 2018 09:15:07 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74547130F6C for ; Wed, 18 Jul 2018 09:15:07 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id C23D3BA7; Wed, 18 Jul 2018 12:13:16 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CAAD6686-4E0D-4429-AEEC-1B2025F28773" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 12:15:05 -0400 In-Reply-To: <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:15:12 -0000 --Apple-Mail=_CAAD6686-4E0D-4429-AEEC-1B2025F28773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. = So either you search for _dns-update._udp. and use TCP or you = register _tcp. And while you could use an EDNS(0) OPT RR to set the maximum UDP packet = size larger than 512, you probably wouldn=E2=80=99t want to set it = larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. Tom > On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: >=20 > If you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP. > The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >=20 > Thanks, > Tom >=20 >> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>=20 >> Tim pointed out that we need to protect the Service Instance Name as = well as the Host Description with a KEY record, because FCFS naming has = to protect both the service description and the host description. Here = are the changes: >>=20 >> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>=20 >> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >> The question of whether we update RFC6763 is basically "is there text = that is in RFC6763 that is no longer correct because of this document." = I think the answer is no. >>=20 >> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: >> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>=20 >> Thanks, >> Tom >>=20 >>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>=20 >>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried = to harmonize the document toward that=E2=80=94did I miss something? >>>=20 >>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: >>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>=20 >>> Is this meant to distinguish from RFC 6763? >>> =20 >>> Thanks, >>> Tom >>>=20 >>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>=20 >>>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>=20 >>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>> Ted Lemon > writes: >>>>=20 >>>> Why can't it be just a Host Description? Might be useful for a = device >>>> that just wants to register its name but doesn't (currently, or = ever) >>>> advertise any services... >>>>=20 >>>> Good question. What does the working group think? :)=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_CAAD6686-4E0D-4429-AEEC-1B2025F28773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> and use = TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set = the maximum UDP packet size larger than 512, you probably wouldn=E2=80=99t= want to set it larger than the MTU and 1480 isn=E2=80=99t big enough = for 3 KEYs plus other records.

Tom

On Jul = 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

If you are adding more = KEY records, you will certainly exceed the UDP update size of 512 bytes. = The draft doesn=E2=80=99t mention transport but maybe this should be = restricted to TCP.
The draft does mention searching for = the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be = able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> = wrote:

Tim pointed out that we need to protect the = Service Instance Name as well as the Host Description with a KEY record, = because FCFS naming has to protect both the service description and the = host description.   Here are the changes:

https://github.com/StuartCheshire/draft-sctl-service-registrati= on/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d= 544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul = 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 = is DNS-Based Service Discovery.   So I tried to harmonize the = document toward that=E2=80=94did I miss something?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on = github now includes fixes for all the points that have been raised other = than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_CAAD6686-4E0D-4429-AEEC-1B2025F28773-- From nobody Wed Jul 18 09:25:07 2018 Return-Path: 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 D65F11311D4 for ; Wed, 18 Jul 2018 09:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LSZTHi9DE1xd for ; Wed, 18 Jul 2018 09:25:03 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89341311CE for ; Wed, 18 Jul 2018 09:25:02 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3E61BBAE; Wed, 18 Jul 2018 12:23:12 -0400 (EDT) From: Tom Pusateri Message-Id: <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9E39BA17-F1DF-46C6-81DB-9DF276512073" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 12:25:00 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:25:06 -0000 --Apple-Mail=_9E39BA17-F1DF-46C6-81DB-9DF276512073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. Searching for _dns-update._udp. still seems odd but that=E2=80=99s= been going on for a while a presume. Tom > On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: >=20 > Looking in the IANA registry, dns-update isn=E2=80=99t assigned for = TCP. So either you search for _dns-update._udp. and use TCP or = you register _tcp. >=20 > And while you could use an EDNS(0) OPT RR to set the maximum UDP = packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. >=20 > Tom >=20 >> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>=20 >> If you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP. >> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>=20 >> Thanks, >> Tom >>=20 >>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>=20 >>> Tim pointed out that we need to protect the Service Instance Name as = well as the Host Description with a KEY record, because FCFS naming has = to protect both the service description and the host description. Here = are the changes: >>>=20 >>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>=20 >>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>> The question of whether we update RFC6763 is basically "is there = text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>=20 >>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: >>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>=20 >>> Thanks, >>> Tom >>>=20 >>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>=20 >>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried = to harmonize the document toward that=E2=80=94did I miss something? >>>>=20 >>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: >>>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>>=20 >>>> Is this meant to distinguish from RFC 6763? >>>> =20 >>>> Thanks, >>>> Tom >>>>=20 >>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>=20 >>>>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>=20 >>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>>> Ted Lemon > writes: >>>>>=20 >>>>> Why can't it be just a Host Description? Might be useful for a = device >>>>> that just wants to register its name but doesn't (currently, or = ever) >>>>> advertise any services... >>>>>=20 >>>>> Good question. What does the working group think? :)=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_9E39BA17-F1DF-46C6-81DB-9DF276512073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = saw this in Section 2: "By requiring the use of TCP, the possibility of = off-network spoofing is eliminated=E2=80=9D. So requiring TCP is already = handled.

Searching = for _dns-update._udp.<domain> still seems odd but that=E2=80=99= s been going on for a while a presume.

Tom

On Jul = 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

Looking in the IANA = registry, dns-update isn=E2=80=99t assigned for TCP. So either you = search for _dns-update._udp.<domain> and use TCP or you register = _tcp.

And while you could use an = EDNS(0) OPT RR to set the maximum UDP packet size larger than 512, you = probably wouldn=E2=80=99t want to set it larger than the MTU and 1480 = isn=E2=80=99t big enough for 3 KEYs plus other records.

Tom

On Jul = 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

If you are adding more = KEY records, you will certainly exceed the UDP update size of 512 bytes. = The draft doesn=E2=80=99t mention transport but maybe this should be = restricted to TCP.
The draft does mention searching for = the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be = able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> = wrote:

Tim pointed out that we need to protect the = Service Instance Name as well as the Host Description with a KEY record, = because FCFS naming has to protect both the service description and the = host description.   Here are the changes:

https://github.com/StuartCheshire/draft-sctl-service-registrati= on/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d= 544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul = 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 = is DNS-Based Service Discovery.   So I tried to harmonize the = document toward that=E2=80=94did I miss something?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on = github now includes fixes for all the points that have been raised other = than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_9E39BA17-F1DF-46C6-81DB-9DF276512073-- From nobody Wed Jul 18 09:27:59 2018 Return-Path: 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 39CB813119B for ; Wed, 18 Jul 2018 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 NtyjVc2832Fo for ; Wed, 18 Jul 2018 09:27:53 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A619F130E9E for ; Wed, 18 Jul 2018 09:27:53 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 188-v6so5139246ita.5 for ; Wed, 18 Jul 2018 09:27:53 -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=rodv01DM0AoyQrIjSKfUBFrcDwWONTXR+34D3Xrcia0=; b=h1BzvDT+Dpec7/8CAyGx3XaHD1Qe9KYeSocx2N1ZC1ut1+k14wmJbLuewSoweVia8L 2N0UC6zDSGeyRujaESnxJ+MwPgpf4icXOa+N520jE11H6ox/SmrtOFcuMUpR5gP0HR3t rt73Akr25vZiuJiElAHwkfa+GeOvq/vsRQ/snLsffrpHpnKiHqyEeuQZSgzIgBSoQQyi EM2lhuhnXMf4Du2i9iLcJE4u7PwHRSAu8f2eyFdAXpXSxgf0nOLrKXdub5rcxtIvb2eU rwxt56HTcL2orWHl1l3u7bG88ZgYQfbr8w4Cc6bad2yFg/amMAFDQAYYh7VbvvLBVb5a WF3g== 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=rodv01DM0AoyQrIjSKfUBFrcDwWONTXR+34D3Xrcia0=; b=tMY10QuMyYdbG3MYvTQ5O8hTA80I66eAETMJIIsJQ8nfjZBJsc5uhxRWO94nlSHOX4 GzH7Gjk8AzB3nrYKdoxHqhhdyYYSM9jwR0diUcM5hGicW1lNDW1bZV8EZtkZ+BDNb/lw 0HAM0kSHxAjwgmLXkJA9+JRcMdbH9bVjD8BY9lYQ5H0Clvl3B9bQ+EFI6Q6BHD8q7G54 F3XnwxKqzY6OtUbWfwd8mudZ7LE+D46+o1IsVBkrYwTdhvM0DUHexSHLGhLeZs6xhH6c R/piQ0YqM4bjBKhfp3PVeYaj0F3Y8UrK/ojxso9CLzBJY0AsG5lbmwHCgrcm+ZASPO+S cKaw== X-Gm-Message-State: AOUpUlF7tWK3Lp2MgHo56YYO7hoEUL+77FSyYdX5OFLCRE9wME6ZcKcO gVlFnya60BFRH7OA58D5SOnk03UVOhanEq5TQi10nQ== X-Google-Smtp-Source: AAOMgpf+pUO/dpe5k3IelBpHpaopJYH5myLYCtJYgwRp896zvxgfSPqGPgv0iRbK/310rxTGN1tUiTQKe8PdpZA0I3g= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr2719765itg.82.1531931272689; Wed, 18 Jul 2018 09:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 09:27:12 -0700 (PDT) In-Reply-To: <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> From: Ted Lemon Date: Wed, 18 Jul 2018 12:27:12 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000054577e0571488ba5" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:27:58 -0000 --00000000000054577e0571488ba5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of course, you still have a very good point in that the anycast update method relies on UDP, so sending the key multiple times isn't desirable. But I also don't see a way around this. We could have the server replicate the key, I guess. On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri wrote: > Just saw this in Section 2: "By requiring the use of TCP, the possibility > of off-network spoofing is eliminated=E2=80=9D. So requiring TCP is alrea= dy handled. > > Searching for _dns-update._udp. still seems odd but that=E2=80=99= s been > going on for a while a presume. > > Tom > > > On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: > > Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. = So either > you search for _dns-update._udp. and use TCP or you register _tcp= . > > And while you could use an EDNS(0) OPT RR to set the maximum UDP packet > size larger than 512, you probably wouldn=E2=80=99t want to set it larger= than the > MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records. > > Tom > > On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: > > If you are adding more KEY records, you will certainly exceed the UDP > update size of 512 bytes. The draft doesn=E2=80=99t mention transport but= maybe > this should be restricted to TCP. > The draft does mention searching for the update server using > _dns-update._udp.. But then it won=E2=80=99t be able to use UDP f= or > updates. > > Thanks, > Tom > > On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: > > Tim pointed out that we need to protect the Service Instance Name as well > as the Host Description with a KEY record, because FCFS naming has to > protect both the service description and the host description. Here are > the changes: > > https://github.com/StuartCheshire/draft-sctl-service-registration/compare= / > ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8 > da85874597 > > On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: > >> The question of whether we update RFC6763 is basically "is there text >> that is in RFC6763 that is no longer correct because of this document." = I >> think the answer is no. >> >> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote= : >> >>> Ok, just checking. So given that 6763 semi-defines service registration >>> protocol as DNS Dynamic Update, should this document claim it updates 6= 763? >>> >>> Thanks, >>> Tom >>> >>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>> >>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >>> harmonize the document toward that=E2=80=94did I miss something? >>> >>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>> wrote: >>> >>>> How is DNS-Based Service Discovery different from DNS Service >>>> Discovery? >>>> >>>> Is this meant to distinguish from RFC 6763? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>> >>>> BTW, the current version of the document on github now includes fixes >>>> for all the points that have been raised other than the ones I said I >>>> wasn't going to fix: https://github.com/Stuart >>>> Cheshire/draft-sctl-service-registration >>>> >>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>> >>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>>>> wrote: >>>>> >>>>>> Ted Lemon writes: >>>>>> >>>>>> Why can't it be just a Host Description? Might be useful for a devic= e >>>>>> that just wants to register its name but doesn't (currently, or ever= ) >>>>>> advertise any services... >>>>>> >>>>>> Good question. What does the working group think? :) >>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --00000000000054577e0571488ba5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of course, you still have a very good point in that the an= ycast update method relies on UDP, so sending the key multiple times isn= 9;t desirable.=C2=A0 =C2=A0But I also don't see a way around this.=C2= =A0 =C2=A0We could have the server replicate the key, I guess.

On Wed, Jul 18, 2018 at = 12:25 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of T= CP, the possibility of off-network spoofing is eliminated=E2=80=9D. So requ= iring TCP is already handled.

Searching for=C2=A0_dns-up= date._udp.<domain> still seems odd but that=E2=80=99s been going on f= or a while a presume.
<= div>
Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote= :

Looking in t= he IANA registry, dns-update isn=E2=80=99t assigned for TCP. So either you = search for _dns-update._udp.<domain= > and use TCP or you register _tcp.

And = while you could use an EDNS(0) OPT RR to set the maximum UDP packet size la= rger than 512, you probably wouldn=E2=80=99t want to set it larger than the= MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:
If you are addi= ng more KEY records, you will certainly exceed the UDP update size of 512 b= ytes. The draft doesn=E2=80=99t mention transport but maybe this should be = restricted to TCP.
The draft does mention searching for the update serv= er using=C2=A0_dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim poi= nted out that we need to protect the Service Instance Name as well as the H= ost Description with a KEY record, because FCFS naming has to protect both = the service description and the host description.=C2=A0 =C2=A0Here are the = changes:

=
On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <= span dir=3D"ltr"><= mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically &q= uot;is there text that is in RFC6763 that is no longer correct because of t= his document."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:4= 1 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service r= egistration protocol as DNS Dynamic Update, should this document claim it u= pdates 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:<= /div>
The title of RFC 6= 763 is DNS-Based Service Discovery.=C2=A0 =C2=A0So I tried to harmonize the= document toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, To= m Pusateri <pusateri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery diffe= rent from DNS Service Discovery?

Is this meant to distingu= ish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

<= blockquote type=3D"cite">
BTW, the current version of = the document on github now includes fixes for all the points that have been= raised other than the ones I said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-service-re<= wbr>gistration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com>= wrote:
On Mon, Jul 16, 2018 at 5:2= 7 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2= =A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman= /listinfo/dnssd

=
--00000000000054577e0571488ba5-- From nobody Wed Jul 18 09:48:34 2018 Return-Path: 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 CE8F4130EDE for ; Wed, 18 Jul 2018 09:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 i9XlQqlLDraO for ; Wed, 18 Jul 2018 09:48:29 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB932130DF1 for ; Wed, 18 Jul 2018 09:48:28 -0700 (PDT) Received: from dhcp-9194.meeting.ietf.org (dhcp-9194.meeting.ietf.org [31.133.145.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 133D3BBA; Wed, 18 Jul 2018 12:46:38 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EDE9D2EF-C96D-45B3-829D-782E9EE8A683" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 12:48:26 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:48:33 -0000 --Apple-Mail=_EDE9D2EF-C96D-45B3-829D-782E9EE8A683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP. Tom > On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >=20 > Of course, you still have a very good point in that the anycast update = method relies on UDP, so sending the key multiple times isn't desirable. = But I also don't see a way around this. We could have the server = replicate the key, I guess. >=20 > On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri > wrote: > Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. >=20 > Searching for _dns-update._udp. still seems odd but that=E2=80=99= s been going on for a while a presume. >=20 > Tom >=20 >=20 >> On Jul 18, 2018, at 12:15 PM, Tom Pusateri > wrote: >>=20 >> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for = TCP. So either you search for _dns-update._udp. and use TCP or = you register _tcp. >>=20 >> And while you could use an EDNS(0) OPT RR to set the maximum UDP = packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. >>=20 >> Tom >>=20 >>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>>=20 >>> If you are adding more KEY records, you will certainly exceed the = UDP update size of 512 bytes. The draft doesn=E2=80=99t mention = transport but maybe this should be restricted to TCP. >>> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>>=20 >>> Thanks, >>> Tom >>>=20 >>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>>=20 >>>> Tim pointed out that we need to protect the Service Instance Name = as well as the Host Description with a KEY record, because FCFS naming = has to protect both the service description and the host description. = Here are the changes: >>>>=20 >>>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>>=20 >>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>>> The question of whether we update RFC6763 is basically "is there = text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>>=20 >>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: >>>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>>=20 >>>> Thanks, >>>> Tom >>>>=20 >>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>>=20 >>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried = to harmonize the document toward that=E2=80=94did I miss something? >>>>>=20 >>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: >>>>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>>>=20 >>>>> Is this meant to distinguish from RFC 6763? >>>>> =20 >>>>> Thanks, >>>>> Tom >>>>>=20 >>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>>=20 >>>>>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>>=20 >>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>>>> Ted Lemon > writes: >>>>>>=20 >>>>>> Why can't it be just a Host Description? Might be useful for a = device >>>>>> that just wants to register its name but doesn't (currently, or = ever) >>>>>> advertise any services... >>>>>>=20 >>>>>> Good question. What does the working group think? :)=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>=20 >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_EDE9D2EF-C96D-45B3-829D-782E9EE8A683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP.

Tom

On Jul 18, 2018, at 12:27 PM, Ted Lemon = <mellon@fugue.com> wrote:

Of course, you still have a very good point in that the = anycast update method relies on UDP, so sending the key multiple times = isn't desirable.   But I also don't see a way around = this.   We could have the server replicate the key, I = guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled.

Searching for _dns-update._udp.<domain> still = seems odd but that=E2=80=99s been going on for a while a = presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> = and use TCP or you register _tcp.

And while = you could use an EDNS(0) OPT RR to set the maximum UDP packet size = larger than 512, you probably wouldn=E2=80=99t want to set it larger = than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for = updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon = <mellon@fugue.com> wrote:

Tim pointed out that we need to = protect the Service Instance Name as well as the Host Description with a = KEY record, because FCFS naming has to protect both the service = description and the host description.   Here are the = changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, = Tom Pusateri <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The= title of RFC 6763 is DNS-Based Service Discovery.   So I = tried to harmonize the document toward that=E2=80=94did I miss = something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted = Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on = github now includes fixes for all the points that have been raised other = than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_EDE9D2EF-C96D-45B3-829D-782E9EE8A683-- From nobody Wed Jul 18 10:09:37 2018 Return-Path: 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 DC1BF130E0D for ; Wed, 18 Jul 2018 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 rE19Y330bYsA for ; Wed, 18 Jul 2018 10:09:31 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 5AEC2130E0A for ; Wed, 18 Jul 2018 10:09:31 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id j185-v6so5366088ite.1 for ; Wed, 18 Jul 2018 10:09:31 -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=zIjP7NjCWtNwBt18hlvm5301FIr6lWcm9oIpn4gzCyw=; b=XlVqnvsj67nM29h9gQFBf7VenoQrqsqhs/VUTuqgLZGsR7xZHRQm1kFnI/4MNkTAiQ HfZlXFX1cTC14vXtngMj/wCIPr2WJBC5ytz9ZJv7efAPNIBmXg/k58cdUn2waMy48mvI p3qBpbKIW3u35r4bk4lTyRVoZ1xIH7SQmRenRJybSUMXQEmwFJmjq5rSPa8qH1eG6A0T a797dgJd5qugmu6bi0rOcmjIjWQUcUqYXUTa72YsSQXXWjS5ptjlnl/LcBS+oW3S6t4g LZXPne7uvVb1xBL+LgQhwLIE5BClqBT6By1mCuQunzpRtMAegTxFBc3VCmAGfqKqnn4n AIaA== 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=zIjP7NjCWtNwBt18hlvm5301FIr6lWcm9oIpn4gzCyw=; b=GkiYM46xImGLmfyfyRy6exXkM7fx3E9zqwbJAdxBWr+FCE0H7n0qLuxufflisFX2S6 hvQLAMIQRP612ObdE32ZtNSyJkpky2uvqB4CokjkrYrOpGVe/S0ITVArA0eu6uomrgBK DF9wItE84KtpkmIYzZr3dQ4fn8RAAhrKEfesKROvYg8kwo0fXJ5ucyJ/jGKj6JNNxouH yVoV+eZTBFmbPCe7XcZA/Js1g4eY3AGt4+G7QaAmwyStb6HPpQZBPFNshcg3AhWDJsVk SWMkuQJz5R1Xtnj/JE2DbXRrSVEFDZqXEgcfEz/xmvzobBdvG/wj4ad2NqjrNcQsNm// 4R/w== X-Gm-Message-State: AOUpUlHBKNorMBOVqjGJ9hPBkyHuUeIZpST+lSXKg+mu+zAftv+VQ8OH wQEqli0RAPsN0fGAFrcOS8Hnt582Wd+YZeWk8z6kkw== X-Google-Smtp-Source: AAOMgpffoj8BZu6jDnUw3q/KIOXFWvlcFjxbsqG56dhmTA5UNltMVqQCDvN2xtKumehQiUXGx9efx1Lg6fn3vy7bz2U= X-Received: by 2002:a24:8a85:: with SMTP id v127-v6mr1440917itd.98.1531933770578; Wed, 18 Jul 2018 10:09:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 10:08:49 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> From: Ted Lemon Date: Wed, 18 Jul 2018 13:08:49 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000037149905714920cf" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 17:09:35 -0000 --00000000000037149905714920cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm, you're right, that's never stated explicitly. On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri wrote: > I don=E2=80=99t see anywhere in the document where the anycast update met= hod > relies on UDP. > > Tom > > > On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: > > Of course, you still have a very good point in that the anycast update > method relies on UDP, so sending the key multiple times isn't desirable. > But I also don't see a way around this. We could have the server > replicate the key, I guess. > > On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri wrote= : > >> Just saw this in Section 2: "By requiring the use of TCP, the possibilit= y >> of off-network spoofing is eliminated=E2=80=9D. So requiring TCP is alre= ady handled. >> >> Searching for _dns-update._udp. still seems odd but that=E2=80= =99s been >> going on for a while a presume. >> >> Tom >> >> >> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: >> >> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TCP.= So >> either you search for _dns-update._udp. and use TCP or you >> register _tcp. >> >> And while you could use an EDNS(0) OPT RR to set the maximum UDP packet >> size larger than 512, you probably wouldn=E2=80=99t want to set it large= r than the >> MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records. >> >> Tom >> >> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: >> >> If you are adding more KEY records, you will certainly exceed the UDP >> update size of 512 bytes. The draft doesn=E2=80=99t mention transport bu= t maybe >> this should be restricted to TCP. >> The draft does mention searching for the update server using >> _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for >> updates. >> >> Thanks, >> Tom >> >> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >> >> Tim pointed out that we need to protect the Service Instance Name as wel= l >> as the Host Description with a KEY record, because FCFS naming has to >> protect both the service description and the host description. Here ar= e >> the changes: >> >> https://github.com/StuartCheshire/draft-sctl-service- >> registration/compare/ae53618d8231733701ccdda4d336692a529c9f6 >> b...5c85181881b84ed1132d544e157df8da85874597 >> >> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >> >>> The question of whether we update RFC6763 is basically "is there text >>> that is in RFC6763 that is no longer correct because of this document."= I >>> think the answer is no. >>> >>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>> wrote: >>> >>>> Ok, just checking. So given that 6763 semi-defines service registratio= n >>>> protocol as DNS Dynamic Update, should this document claim it updates = 6763? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>> >>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >>>> harmonize the document toward that=E2=80=94did I miss something? >>>> >>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>> wrote: >>>> >>>>> How is DNS-Based Service Discovery different from DNS Service >>>>> Discovery? >>>>> >>>>> Is this meant to distinguish from RFC 6763? >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>> >>>>> BTW, the current version of the document on github now includes fixes >>>>> for all the points that have been raised other than the ones I said I >>>>> wasn't going to fix: https://github.com/Stuart >>>>> Cheshire/draft-sctl-service-registration >>>>> >>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>>> >>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen >>>>> > wrote: >>>>>> >>>>>>> Ted Lemon writes: >>>>>>> >>>>>>> Why can't it be just a Host Description? Might be useful for a devi= ce >>>>>>> that just wants to register its name but doesn't (currently, or eve= r) >>>>>>> advertise any services... >>>>>>> >>>>>>> Good question. What does the working group think? :) >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --00000000000037149905714920cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm, you're right, that's never stated explicitly.<= /div>

On Wed, Jul = 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com> wro= te:
I don=E2=80=99t see anywhere in the document wh= ere the anycast update method relies on UDP.

Tom


=
On Jul 18, 2018, at 12:27 PM, Ted Lemon <= mellon@fugue.com&= gt; wrote:

Of course, you still have a very good point in tha= t the anycast update method relies on UDP, so sending the key multiple time= s isn't desirable.=C2=A0 =C2=A0But I also don't see a way around th= is.=C2=A0 =C2=A0We could have the server replicate the key, I guess.
<= div class=3D"gmail_extra">
On Wed, Jul 18, 20= 18 at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the us= e of TCP, the possibility of off-network spoofing is eliminated=E2=80=9D. S= o requiring TCP is already handled.

Searching for=C2=A0_= dns-update._udp.<domain> still seems odd but that=E2=80=99s been goin= g on for a while a presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Looking in the IANA registry, dns-update isn=E2=80=99t assigned for T= CP. So either you search for _dns-upda= te._udp.<domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set the maximum = UDP packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus ot= her records.

Tom

<= blockquote type=3D"cite">
On Jul 18, 2018, at 12:05 PM, Tom Pusateri &l= t;pusateri@bangj.co= m> wrote:

If you are adding more KEY records, you will certa= inly exceed the UDP update size of 512 bytes. The draft doesn=E2=80=99t men= tion transport but maybe this should be restricted to TCP.
The draft do= es mention searching for the update server using=C2=A0_dns-update._udp.<domain>. But then it won=E2=80= =99t be able to use UDP for updates.

= Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted L= emon <mellon@fugue= .com> wrote:

Tim pointed out that= we need to protect the Service Instance Name as well as the Host Descripti= on with a KEY record, because FCFS naming has to protect both the service d= escription and the host description.=C2=A0 =C2=A0Here are the changes:
=

On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon &= lt;mellon@fugue.com> wrote:
= The question of whether we update RFC6763 is basically "is there text = that is in RFC6763 that is no longer correct because of this document."= ;=C2=A0 I think the answer is no.

On= Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
Ok, just checking. So given that = 6763 semi-defines service registration protocol as DNS Dynamic Update, shou= ld this document claim it updates 6763?

Thanks,
Tom

On Jul= 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 i= s DNS-Based Service Discovery.=C2=A0 =C2=A0So I tried to harmonize the docu= ment toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pus= ateri <pusateri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery different f= rom DNS Service Discovery?

Is this meant to distinguish fr= om RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:<= br>
BTW, the curre= nt version of the document on github now includes fixes for all the points = that have been raised other than the ones I said I wasn't going to fix:= =C2=A0https://github.com/StuartCheshire/draft-sct= l-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugu= e.com> wrote:
On Mon, Jul = 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <= ;toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> = writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Goo= d question.=C2=A0 =C2=A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailma= n/listinfo/dnssd


_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd


--00000000000037149905714920cf-- From nobody Wed Jul 18 16:37:53 2018 Return-Path: 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 88CC7131029 for ; Wed, 18 Jul 2018 16:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uO_ef-YcpTCi for ; Wed, 18 Jul 2018 16:37:48 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C212F130DF2 for ; Wed, 18 Jul 2018 16:37:47 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id B90E2C6D; Wed, 18 Jul 2018 19:35:55 -0400 (EDT) From: Tom Pusateri Message-Id: <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDE0C50E-9192-4A89-8008-008973A60427" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 19:37:45 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 23:37:52 -0000 --Apple-Mail=_BDE0C50E-9192-4A89-8008-008973A60427 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tim and I were talking and we were wondering if one client could delete = the PTR record for a service instance that another client created? Seems = like it=E2=80=99s not protected and could be a denial of service attack? = So you might need a KEY record the PTR record. Tom > On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >=20 > Hm, you're right, that's never stated explicitly. >=20 > On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri > wrote: > I don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP. >=20 > Tom >=20 >=20 >> On Jul 18, 2018, at 12:27 PM, Ted Lemon > wrote: >>=20 >> Of course, you still have a very good point in that the anycast = update method relies on UDP, so sending the key multiple times isn't = desirable. But I also don't see a way around this. We could have the = server replicate the key, I guess. >>=20 >> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri > wrote: >> Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. >>=20 >> Searching for _dns-update._udp. still seems odd but that=E2=80=99= s been going on for a while a presume. >>=20 >> Tom >>=20 >>=20 >>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri > wrote: >>>=20 >>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for = TCP. So either you search for _dns-update._udp. and use TCP or = you register _tcp. >>>=20 >>> And while you could use an EDNS(0) OPT RR to set the maximum UDP = packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. >>>=20 >>> Tom >>>=20 >>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>>>=20 >>>> If you are adding more KEY records, you will certainly exceed the = UDP update size of 512 bytes. The draft doesn=E2=80=99t mention = transport but maybe this should be restricted to TCP. >>>> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>>>=20 >>>> Thanks, >>>> Tom >>>>=20 >>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>>>=20 >>>>> Tim pointed out that we need to protect the Service Instance Name = as well as the Host Description with a KEY record, because FCFS naming = has to protect both the service description and the host description. = Here are the changes: >>>>>=20 >>>>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>>>=20 >>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>>>> The question of whether we update RFC6763 is basically "is there = text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>>>=20 >>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: >>>>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>>>=20 >>>>> Thanks, >>>>> Tom >>>>>=20 >>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>>>=20 >>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I = tried to harmonize the document toward that=E2=80=94did I miss = something? >>>>>>=20 >>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri > wrote: >>>>>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>>>>=20 >>>>>> Is this meant to distinguish from RFC 6763? >>>>>> =20 >>>>>> Thanks, >>>>>> Tom >>>>>>=20 >>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>>>=20 >>>>>>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>>>=20 >>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>>>>> Ted Lemon > writes: >>>>>>>=20 >>>>>>> Why can't it be just a Host Description? Might be useful for a = device >>>>>>> that just wants to register its name but doesn't (currently, or = ever) >>>>>>> advertise any services... >>>>>>>=20 >>>>>>> Good question. What does the working group think? :)=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 >=20 --Apple-Mail=_BDE0C50E-9192-4A89-8008-008973A60427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Tim and I were talking and we were wondering if one client = could delete the PTR record for a service instance that another client = created? Seems like it=E2=80=99s not protected and could be a denial of = service attack? So you might need a KEY record the PTR record.

Tom

On Jul = 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right, that's never stated explicitly.

On Wed, = Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com> wrote:
I = don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP.

Tom


On Jul 18, 2018, at 12:27 PM, Ted Lemon = <mellon@fugue.com> wrote:

Of course, you still have a very = good point in that the anycast update method relies on UDP, so sending = the key multiple times isn't desirable.   But I also don't see = a way around this.   We could have the server replicate the = key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled.

Searching for _dns-update._udp.<domain> still = seems odd but that=E2=80=99s been going on for a while a = presume.

Tom


On Jul = 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> = and use TCP or you register _tcp.

And while = you could use an EDNS(0) OPT RR to set the maximum UDP packet size = larger than 512, you probably wouldn=E2=80=99t want to set it larger = than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for = updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon = <mellon@fugue.com> wrote:

Tim pointed out that we = need to protect the Service Instance Name as well as the Host = Description with a KEY record, because FCFS naming has to protect both = the service description and the host description.   Here are = the changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, = Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, = Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service = Discovery.   So I tried to harmonize the document toward = that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, = Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, = 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the = document on github now includes fixes for all the points that have been = raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...
<= font color=3D"#888888" class=3D"">
Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



= --Apple-Mail=_BDE0C50E-9192-4A89-8008-008973A60427-- From nobody Wed Jul 18 16:40:48 2018 Return-Path: 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 2F9CA130DF2 for ; Wed, 18 Jul 2018 16:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XAB6m3RLCr8g for ; Wed, 18 Jul 2018 16:40:41 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A951310A1 for ; Wed, 18 Jul 2018 16:40:41 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9254DC6F; Wed, 18 Jul 2018 19:38:49 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CF8AD561-B757-4E4E-92E2-A91CDC9B6255" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 19:40:39 -0400 In-Reply-To: <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 23:40:46 -0000 --Apple-Mail=_CF8AD561-B757-4E4E-92E2-A91CDC9B6255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You might not need a new KEY record for the PTR but you may need to = follow the instance of the PTR to a KEY record to make sure you have = permission to delete the PTR record. Tom > On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >=20 > Tim and I were talking and we were wondering if one client could = delete the PTR record for a service instance that another client = created? Seems like it=E2=80=99s not protected and could be a denial of = service attack? So you might need a KEY record the PTR record. >=20 > Tom >=20 >> On Jul 18, 2018, at 1:08 PM, Ted Lemon > wrote: >>=20 >> Hm, you're right, that's never stated explicitly. >>=20 >> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri > wrote: >> I don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP. >>=20 >> Tom >>=20 >>=20 >>> On Jul 18, 2018, at 12:27 PM, Ted Lemon > wrote: >>>=20 >>> Of course, you still have a very good point in that the anycast = update method relies on UDP, so sending the key multiple times isn't = desirable. But I also don't see a way around this. We could have the = server replicate the key, I guess. >>>=20 >>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri > wrote: >>> Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. >>>=20 >>> Searching for _dns-update._udp. still seems odd but that=E2=80= =99s been going on for a while a presume. >>>=20 >>> Tom >>>=20 >>>=20 >>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri > wrote: >>>>=20 >>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for = TCP. So either you search for _dns-update._udp. and use TCP or = you register _tcp. >>>>=20 >>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP = packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. >>>>=20 >>>> Tom >>>>=20 >>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>>>>=20 >>>>> If you are adding more KEY records, you will certainly exceed the = UDP update size of 512 bytes. The draft doesn=E2=80=99t mention = transport but maybe this should be restricted to TCP. >>>>> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>>>>=20 >>>>> Thanks, >>>>> Tom >>>>>=20 >>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>>>>=20 >>>>>> Tim pointed out that we need to protect the Service Instance Name = as well as the Host Description with a KEY record, because FCFS naming = has to protect both the service description and the host description. = Here are the changes: >>>>>>=20 >>>>>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>>>>=20 >>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>>>>> The question of whether we update RFC6763 is basically "is there = text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>>>>=20 >>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri > wrote: >>>>>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>>>>=20 >>>>>> Thanks, >>>>>> Tom >>>>>>=20 >>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>>>>=20 >>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I = tried to harmonize the document toward that=E2=80=94did I miss = something? >>>>>>>=20 >>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri = > wrote: >>>>>>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>>>>>=20 >>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>> =20 >>>>>>> Thanks, >>>>>>> Tom >>>>>>>=20 >>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>>>>=20 >>>>>>>> BTW, the current version of the document on github now includes = fixes for all the points that have been raised other than the ones I = said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>>>>=20 >>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen= > wrote: >>>>>>>> Ted Lemon > writes: >>>>>>>>=20 >>>>>>>> Why can't it be just a Host Description? Might be useful for a = device >>>>>>>> that just wants to register its name but doesn't (currently, or = ever) >>>>>>>> advertise any services... >>>>>>>>=20 >>>>>>>> Good question. What does the working group think? :)=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>=20 >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd = >>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_CF8AD561-B757-4E4E-92E2-A91CDC9B6255 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = might not need a new KEY record for the PTR but you may need to follow = the instance of the PTR to a KEY record to make sure you have permission = to delete the PTR record.

Tom

On Jul 18, 2018, at 7:37 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

Tim = and I were talking and we were wondering if one client could delete the = PTR record for a service instance that another client created? Seems = like it=E2=80=99s not protected and could be a denial of service attack? = So you might need a KEY record the PTR record.

Tom

On Jul = 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right, that's never stated explicitly.

On Wed, = Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com> wrote:
I = don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP.

Tom


On Jul 18, 2018, at 12:27 PM, Ted Lemon = <mellon@fugue.com> wrote:

Of course, you still have a very = good point in that the anycast update method relies on UDP, so sending = the key multiple times isn't desirable.   But I also don't see = a way around this.   We could have the server replicate the = key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled.

Searching for _dns-update._udp.<domain> still = seems odd but that=E2=80=99s been going on for a while a = presume.

Tom


On Jul = 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> = and use TCP or you register _tcp.

And while = you could use an EDNS(0) OPT RR to set the maximum UDP packet size = larger than 512, you probably wouldn=E2=80=99t want to set it larger = than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for = updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon = <mellon@fugue.com> wrote:

Tim pointed out that we = need to protect the Service Instance Name as well as the Host = Description with a KEY record, because FCFS naming has to protect both = the service description and the host description.   Here are = the changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, = Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, = Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service = Discovery.   So I tried to harmonize the document toward = that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, = Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul 16, = 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the = document on github now includes fixes for all the points that have been = raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...
<= font color=3D"#888888" class=3D"">
Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_CF8AD561-B757-4E4E-92E2-A91CDC9B6255-- From nobody Wed Jul 18 17:28:25 2018 Return-Path: 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 BE854130E4F for ; Wed, 18 Jul 2018 17:28:23 -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 RL1k-NMcoxAf for ; Wed, 18 Jul 2018 17:28:19 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 00E6A13107F for ; Wed, 18 Jul 2018 17:28:18 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id w16-v6so6769554ita.0 for ; Wed, 18 Jul 2018 17:28:18 -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=qzc7fy9RO7qy9cVblrwSdlPq9heiNE2i/GWwh3iZ22k=; b=RKhZwemUaWmro37sIwcDAiGmhgyej3wkfmTCrWJ6mqfxBpkavmsno2AyfRqgqCRFAJ SDo0nFfLDlCKs4+dLzU+IP3Th7y6gTlDUF+JcInnhpJLaY3bPA37uxmNRJLNi9YADjcV ncElr1O7y1PcyAAwNVhcPlVw7poluAysTZOLO0g3YDIrxLPbANPKRVdJupRCJ45ASP09 b3wERE6Wr1D+RbPrPiFbvopinvtAoA6T5f/N42lvRujhWYD0a+I2O2D0aCk53IdTg2AT BvBYnkb1Qi0UUhalLQ5GbJOmULAvG7hSgcDLdZumosHWZCpQtyq3osHBaAr6cAkZL67+ BeXA== 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=qzc7fy9RO7qy9cVblrwSdlPq9heiNE2i/GWwh3iZ22k=; b=EyuUwCYnLyXFAT89DC7YEJgvU2S2FFFbTpjVgDoQt19dw7xbPt0/1igkUV/ZD+gy42 Z8kV0iSpVOUc/RNxl7B8NI5QEAjMBzETNkOrCsAv04lztVQzSGiuzylBfQn1XAX68e9l NPvXQejSnASOhARi6weoHukbV/nlQGylX3OJwuJYnams5dqPI7jxKlqavYVFOmlp8ky0 QaC0jlDG/9dmWXD29z5VqhKrmLj276/a2OTM/jlhAlUrQJAEO1c+9O+aZzEntmLqdYml D5/upzdw5Ionr/kVV7teyd4JqsJb7UgK9QWibeLJV37FMh6S41hiYIv6FpsIiMrZnlB/ uipw== X-Gm-Message-State: AOUpUlGVvcC/Hi9ztgvs6jU8hOgbSzYP6dOByyIaAVdLOWB7Xfkxwh/4 w1WLLbOEbmmP6CgIRVmr5ITlR/6xY6mR2ZAf7/ctWQ== X-Google-Smtp-Source: AAOMgpeGHDiZe/G4RDfXefr/2D+G1AZsT3j68OXtzzIWHIxpXIvb/eS2hJYdNNJNoakX8Kx1/x0FfwoROch3DgivJJE= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr7275968jad.38.1531960098122; Wed, 18 Jul 2018 17:28:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 17:27:37 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> From: Ted Lemon Date: Wed, 18 Jul 2018 20:27:37 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000075881a05714f41bc" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:28:24 -0000 --00000000000075881a05714f41bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You can't delete anything from a service name. Maybe we need to say that more explicitly. Right now the protocol doesn't allow a service to delete itself; only to add itself. The assumption is that the service will not know in advance that it is leaving the network, so service entries get garbage collected, rather than being explicitly deleted. Compare to DHCPRELEASE in the DHCP protocol, which is pretty useless. On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri wrote: > You might not need a new KEY record for the PTR but you may need to follo= w > the instance of the PTR to a KEY record to make sure you have permission = to > delete the PTR record. > > Tom > > > On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: > > Tim and I were talking and we were wondering if one client could delete > the PTR record for a service instance that another client created? Seems > like it=E2=80=99s not protected and could be a denial of service attack? = So you > might need a KEY record the PTR record. > > Tom > > On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: > > Hm, you're right, that's never stated explicitly. > > On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri wrote= : > >> I don=E2=80=99t see anywhere in the document where the anycast update me= thod >> relies on UDP. >> >> Tom >> >> >> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >> >> Of course, you still have a very good point in that the anycast update >> method relies on UDP, so sending the key multiple times isn't desirable. >> But I also don't see a way around this. We could have the server >> replicate the key, I guess. >> >> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >> wrote: >> >>> Just saw this in Section 2: "By requiring the use of TCP, the >>> possibility of off-network spoofing is eliminated=E2=80=9D. So requirin= g TCP is >>> already handled. >>> >>> Searching for _dns-update._udp. still seems odd but that=E2=80= =99s been >>> going on for a while a presume. >>> >>> Tom >>> >>> >>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: >>> >>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TCP= . So >>> either you search for _dns-update._udp. and use TCP or you >>> register _tcp. >>> >>> And while you could use an EDNS(0) OPT RR to set the maximum UDP packet >>> size larger than 512, you probably wouldn=E2=80=99t want to set it larg= er than the >>> MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records. >>> >>> Tom >>> >>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: >>> >>> If you are adding more KEY records, you will certainly exceed the UDP >>> update size of 512 bytes. The draft doesn=E2=80=99t mention transport b= ut maybe >>> this should be restricted to TCP. >>> The draft does mention searching for the update server using >>> _dns-update._udp.. But then it won=E2=80=99t be able to use UDP= for >>> updates. >>> >>> Thanks, >>> Tom >>> >>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>> >>> Tim pointed out that we need to protect the Service Instance Name as >>> well as the Host Description with a KEY record, because FCFS naming has= to >>> protect both the service description and the host description. Here a= re >>> the changes: >>> >>> https://github.com/StuartCheshire/draft-sctl-service-registr >>> ation/compare/ae53618d8231733701ccdda4d336692a529c9f6b... >>> 5c85181881b84ed1132d544e157df8da85874597 >>> >>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >>> >>>> The question of whether we update RFC6763 is basically "is there text >>>> that is in RFC6763 that is no longer correct because of this document.= " I >>>> think the answer is no. >>>> >>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>> wrote: >>>> >>>>> Ok, just checking. So given that 6763 semi-defines service >>>>> registration protocol as DNS Dynamic Update, should this document cla= im it >>>>> updates 6763? >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>> >>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried to >>>>> harmonize the document toward that=E2=80=94did I miss something? >>>>> >>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>> Discovery? >>>>>> >>>>>> Is this meant to distinguish from RFC 6763? >>>>>> >>>>>> Thanks, >>>>>> Tom >>>>>> >>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>> >>>>>> BTW, the current version of the document on github now includes fixe= s >>>>>> for all the points that have been raised other than the ones I said = I >>>>>> wasn't going to fix: https://github.com/Stuart >>>>>> Cheshire/draft-sctl-service-registration >>>>>> >>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>>>> >>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen < >>>>>>> toke@toke.dk> wrote: >>>>>>> >>>>>>>> Ted Lemon writes: >>>>>>>> >>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>> device >>>>>>>> that just wants to register its name but doesn't (currently, or >>>>>>>> ever) >>>>>>>> advertise any services... >>>>>>>> >>>>>>>> Good question. What does the working group think? :) >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --00000000000075881a05714f41bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can't delete anything from a service name.=C2=A0 = =C2=A0Maybe we need to say that more explicitly.=C2=A0 =C2=A0Right now the = protocol doesn't allow a service to delete itself; only to add itself.= =C2=A0 =C2=A0The assumption is that the service will not know in advance th= at it is leaving the network, so service entries get garbage collected, rat= her than being explicitly deleted.=C2=A0 =C2=A0Compare to DHCPRELEASE in th= e DHCP protocol, which is pretty useless.
<= br>
On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri= <pusateri@bangj.com> wrote:
You mi= ght not need a new KEY record for the PTR but you may need to follow the in= stance of the PTR to a KEY record to make sure you have permission to delet= e the PTR record.

Tom


<= div>On Jul 18, 2018, at 7:37 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Tim and I were tal= king and we were wondering if one client could delete the PTR record for a = service instance that another client created? Seems like it=E2=80=99s not p= rotected and could be a denial of service attack? So you might need a KEY r= ecord the PTR record.

Tom

On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:<= /div>
Hm, you're right, that's never stated explicitly.

On Wed, Jul 18,= 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com> wrote:=
I don=E2=80=99t see anywhere in the document wh= ere the anycast update method relies on UDP.

Tom


On Jul 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wro= te:

Of course, you still have a very go= od point in that the anycast update method relies on UDP, so sending the ke= y multiple times isn't desirable.=C2=A0 =C2=A0But I also don't see = a way around this.=C2=A0 =C2=A0We could have the server replicate the key, = I guess.

On = Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
Just saw this in Section 2: "= ;By requiring the use of TCP, the possibility of off-network spoofing is el= iminated=E2=80=9D. So requiring TCP is already handled.

= Searching for=C2=A0_dns-update._udp.<domain> still seems odd but that= =E2=80=99s been going on for a while a presume.
<= br>
Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com>= ; wrote:

Looking in the IANA registry, dns-up= date isn=E2=80=99t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or yo= u register _tcp.

And while you could use an= EDNS(0) OPT RR to set the maximum UDP packet size larger than 512, you pro= bably wouldn=E2=80=99t want to set it larger than the MTU and 1480 isn=E2= =80=99t big enough for 3 KEYs plus other records.

Tom

On Jul 1= 8, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If you are adding more KEY records, you will certainly exceed the = UDP update size of 512 bytes. The draft doesn=E2=80=99t mention transport b= ut maybe this should be restricted to TCP.
The draft does mention searc= hing for the update server using=C2=A0= _dns-update._udp.<domain>. But then it won=E2=80=99t be able to = use UDP for updates.
=
Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wro= te:

Tim pointed ou= t that we need to protect the Service Instance Name as well as the Host Des= cription with a KEY record, because FCFS naming has to protect both the ser= vice description and the host description.=C2=A0 =C2=A0Here are the changes= :


On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue= .com> wrote:
The question of whether we update RFC6763 is basically "is there= text that is in RFC6763 that is no longer correct because of this document= ."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:4= 1 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service r= egistration protocol as DNS Dynamic Update, should this document claim it u= pdates 6763?

Thanks,
Tom

On Jul 16,= 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The t= itle of RFC 6763 is DNS-Based Service Discovery.=C2=A0 =C2=A0So I tried to = harmonize the document toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 a= t 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is=C2= =A0DNS-Based Service D= iscovery different from DNS Service Discovery?

Is this mea= nt to distinguish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2= 018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document on= github now includes fixes for all the points that have been raised other t= han the ones I said I wasn't going to fix:=C2=A0ht= tps://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, J= ul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3= =B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does the working group t= hink?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailma= n/listinfo/dnssd


_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



___________________________________= ____________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd


--00000000000075881a05714f41bc-- From nobody Wed Jul 18 18:30:31 2018 Return-Path: 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 86A5B130DCA for ; Wed, 18 Jul 2018 18:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SXwnmqsLENJY for ; Wed, 18 Jul 2018 18:30:24 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA77F130E78 for ; Wed, 18 Jul 2018 18:30:23 -0700 (PDT) Received: from [25.56.120.46] (unknown [24.114.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DF97DC87; Wed, 18 Jul 2018 21:28:29 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C5B498DA-6AC8-451D-9938-EE36066642FA Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16A5327f) In-Reply-To: Date: Wed, 18 Jul 2018 21:30:18 -0400 Cc: dnssd Content-Transfer-Encoding: 7bit Message-Id: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> To: Ted Lemon Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 01:30:29 -0000 --Apple-Mail-C5B498DA-6AC8-451D-9938-EE36066642FA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, that needs to be more explicit.=20 If you try to do a delete, does the server send REFUSED? Thanks, Tom > On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >=20 > You can't delete anything from a service name. Maybe we need to say that= more explicitly. Right now the protocol doesn't allow a service to delete= itself; only to add itself. The assumption is that the service will not k= now in advance that it is leaving the network, so service entries get garbag= e collected, rather than being explicitly deleted. Compare to DHCPRELEASE i= n the DHCP protocol, which is pretty useless. >=20 >> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri wrote:= >> You might not need a new KEY record for the PTR but you may need to follo= w the instance of the PTR to a KEY record to make sure you have permission t= o delete the PTR record. >>=20 >> Tom >>=20 >>=20 >>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >>>=20 >>> Tim and I were talking and we were wondering if one client could delete t= he PTR record for a service instance that another client created? Seems like= it=E2=80=99s not protected and could be a denial of service attack? So you m= ight need a KEY record the PTR record. >>>=20 >>> Tom >>>=20 >>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>=20 >>>> Hm, you're right, that's never stated explicitly. >>>>=20 >>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri wro= te: >>>>> I don=E2=80=99t see anywhere in the document where the anycast update m= ethod relies on UDP. >>>>>=20 >>>>> Tom >>>>>=20 >>>>>=20 >>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>>>=20 >>>>>> Of course, you still have a very good point in that the anycast updat= e method relies on UDP, so sending the key multiple times isn't desirable. = But I also don't see a way around this. We could have the server replicat= e the key, I guess. >>>>>>=20 >>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri w= rote: >>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the possib= ility of off-network spoofing is eliminated=E2=80=9D. So requiring TCP is al= ready handled. >>>>>>>=20 >>>>>>> Searching for _dns-update._udp. still seems odd but that=E2=80= =99s been going on for a while a presume. >>>>>>>=20 >>>>>>> Tom >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wro= te: >>>>>>>>=20 >>>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for= TCP. So either you search for _dns-update._udp. and use TCP or you r= egister _tcp. >>>>>>>>=20 >>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP pa= cket size larger than 512, you probably wouldn=E2=80=99t want to set it larg= er than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other reco= rds. >>>>>>>>=20 >>>>>>>> Tom >>>>>>>>=20 >>>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wr= ote: >>>>>>>>>=20 >>>>>>>>> If you are adding more KEY records, you will certainly exceed the U= DP update size of 512 bytes. The draft doesn=E2=80=99t mention transport but= maybe this should be restricted to TCP. >>>>>>>>> The draft does mention searching for the update server using _dns-= update._udp.. But then it won=E2=80=99t be able to use UDP for updat= es. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>>=20 >>>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>>>>>>>=20 >>>>>>>>>> Tim pointed out that we need to protect the Service Instance Name= as well as the Host Description with a KEY record, because FCFS naming has t= o protect both the service description and the host description. Here are t= he changes: >>>>>>>>>>=20 >>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration= /compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e= 157df8da85874597 >>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wr= ote: >>>>>>>>>>> The question of whether we update RFC6763 is basically "is there= text that is in RFC6763 that is no longer correct because of this document.= " I think the answer is no. >>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote: >>>>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service regi= stration protocol as DNS Dynamic Update, should this document claim it updat= es 6763? >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tom >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrot= e: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I t= ried to harmonize the document toward that=E2=80=94did I miss something? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote: >>>>>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service= Discovery? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wr= ote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> BTW, the current version of the document on github now inclu= des fixes for all the points that have been raised other than the ones I sai= d I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-servic= e-registration >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8= rgensen wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Why can't it be just a Host Description? Might be useful f= or a device >>>>>>>>>>>>>>>>> that just wants to register its name but doesn't (currentl= y, or ever) >>>>>>>>>>>>>>>>> advertise any services... >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Good question. What does the working group think? :)=20= >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >=20 --Apple-Mail-C5B498DA-6AC8-451D-9938-EE36066642FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yeah, that needs to be more= explicit. 

If you try to do a delete, does th= e server send REFUSED?

Thanks,
Tom
<= div>
On Jul 18, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a service name.&n= bsp;  Maybe we need to say that more explicitly.   Right now t= he protocol doesn't allow a service to delete itself; only to add itself.&nb= sp;  The assumption is that the service will not know in advance that i= t is leaving the network, so service entries get garbage collected, rather t= han being explicitly deleted.   Compare to DHCPRELEASE in the DHCP= protocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <pusat= eri@bangj.com> wrote:
You might not need= a new KEY record for the PTR but you may need to follow the instance of the= PTR to a KEY record to make sure you have permission to delete the PTR reco= rd.

Tom


On Jul 18, 20= 18, at 7:37 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Tim and I were talking and we were wond= ering if one client could delete the PTR record for a service instance that a= nother client created? Seems like it=E2=80=99s not protected and could be a d= enial of service attack? So you might need a KEY record the PTR record.

Tom

On Jul= 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right= , that's never stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusate= ri@bangj.com> wrote:
I don=E2=80=99t= see anywhere in the document where the anycast update method relies on UDP.=
Tom


On Jul 18, 2018, at 12:27 P= M, Ted Lemon <mello= n@fugue.com> wrote:

Of course, you= still have a very good point in that the anycast update method relies on UD= P, so sending the key multiple times isn't desirable.   But I also= don't see a way around this.   We could have the server replicate= the key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <<= a href=3D"mailto:pusateri@bangj.com" target=3D"_blank">pusateri@bangj.com> wrote:
Just saw this in Section 2: "B= y requiring the use of TCP, the possibility of off-network spoofing is elimi= nated=E2=80=9D. So requiring TCP is already handled.

Sear= ching for _dns-update._udp.<domain> still seems odd but that=E2=80= =99s been going on for a while a presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Looking in the IANA registry, dns-update isn=E2=80=99= t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set t= he maximum UDP packet size larger than 512, you probably wouldn=E2=80=99t wa= nt to set it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEY= s plus other records.
=
Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusat= eri <pusateri@ban= gj.com> wrote:

If you are adding more KEY= records, you will certainly exceed the UDP update size of 512 bytes. The dr= aft doesn=E2=80=99t mention transport but maybe this should be restricted to= TCP.
The draft does mention searching for the update server using = _dns-update._udp.<domain>. B= ut then it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, a= t 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim pointed out that we need to protect the Service Instance N= ame as well as the Host Description with a KEY record, because FCFS naming h= as to protect both the service description and the host description.  &= nbsp;Here are the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted L= emon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically= "is there text that is in RFC6763 that is no longer correct because of this= document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:4= 1 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service regis= tration protocol as DNS Dynamic Update, should this document claim it update= s 6763?

Thanks,
Tom

On Jul 16, 2018, at= 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6= 763 is DNS-Based Service Discovery.   So I tried to harmonize the d= ocument toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pu= sateri <pusateri@bangj.com> wrote:
How is DNS-Based Service Discovery different from= DNS Service Discovery?

Is this meant to distinguish from RFC= 6763?
 
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <= ;mellon@fugue.com&= gt; wrote:

BTW,= the current version of the document on github now includes fixes for all th= e points that have been raised other than the ones I said I wasn't going to f= ix: https://github.com/StuartCheshire/draft-sc= tl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.= com> wrote:
On Mon, Jul 16, 20= 18 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrot= e:
Ted Lemon <mellon@fugue.com> writes:
=
Why can't it be just a Host Description? Might be useful for a de= vice
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group think?&= nbsp;  :) 


________= _______________________________________
dnssd mailing l= ist
dnss= d@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
d= nssd mailing list
dns= sd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_________________________________= ______________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd


_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



____________________________________= ___________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/= dnssd


= --Apple-Mail-C5B498DA-6AC8-451D-9938-EE36066642FA-- From nobody Wed Jul 18 18:37:08 2018 Return-Path: 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 1310D130E98 for ; Wed, 18 Jul 2018 18:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no 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 9jsQjHw_P2F8 for ; Wed, 18 Jul 2018 18:37:03 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 F2B3B130DCA for ; Wed, 18 Jul 2018 18:37:02 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id g141-v6so4738904ita.4 for ; Wed, 18 Jul 2018 18:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tw79f+06kUgNpcIOemgNGagrTT1JMn5SSmeixuuaUFY=; b=C8anok4ADM/p1u0VcdLKV7tv7Rw4KFoW2tXTdjPLgY3/txGVgxbMbbIfXMsAZpgPsh RLuy/EOD06+J7gT4aYDeaesPCXR06D7+JplftY6A4v3+NqAkwN/5exalPr0tiak8bPCB m3gdc/QbG2EvUnmWl/cXEOSgk84HoRMrmEPuH8ZhOPKAxMObGIhBIMjRIsmd67iv18Fa nLBpJ9dcO0ZYpW7xNH3HpvGap618ukBndFBfiTaMvf+oc2dJv/3hW/jH8wezBHugBQyY h09+6Wu0/Os3bQetc2a1hgzmL8XFbmy0H2br3cLmAx/TPtcuTnUKkw51Z3jOVwvrhYFU V93w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tw79f+06kUgNpcIOemgNGagrTT1JMn5SSmeixuuaUFY=; b=qL5okjGAK3JgwOoB0VOhJ91QZE42CJN5FyPa/5tkjpFlJMtZkt3kUVrnHhXrv8RBaQ XoP6vxg1/fBXr+B4oJx7Kjh/v+Sdqb7YhP4Y+Qd5sJL6xTHXNRUDxH98XPrXoFFBH8AY ib8D+P8kcJs+omtXPLxrL5gS20ADI9S0xVaA1TuvGiZ1j8S4k3sAqmuZRg5dIxtRL8T4 XrsL7vU7d20NZgRriNr4YDtPJ2XIVkzlJbMQb2MBBve+uk2UPfFbo+HByVsZZlbqkJQ+ cWFPs7A0+VhEZRbnuL2qYXlYC+SAMh9NzZ5yGkVDefZTE3WJGFUAwYwpPnH3kRH3UO20 zREA== X-Gm-Message-State: AOUpUlHsdi5VrBfxrL6BBzIbEPriGVQzt6apWKcmIRfjQYg4faVxQSPw qlKTsG/c/mYTmaMg2reR5J6ulolJePrdERwcrqvwWw== X-Google-Smtp-Source: AAOMgpelucohgiYOQ5RVaK+vwIgTHqhwDfjFDjGCT083Bcb0ShGuZBCrymhI5yQeZs9UJmqEptswnSlBWNWuR8xyOto= X-Received: by 2002:a24:d485:: with SMTP id x127-v6mr4156678itg.82.1531964222017; Wed, 18 Jul 2018 18:37:02 -0700 (PDT) MIME-Version: 1.0 References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> In-Reply-To: From: Ted Lemon Date: Wed, 18 Jul 2018 21:36:51 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000004336920571503775" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 01:37:06 -0000 --0000000000004336920571503775 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that=E2=80=99s the correct behavior. On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote: > Yeah, that needs to be more explicit. > > If you try to do a delete, does the server send REFUSED? > > Thanks, > Tom > > On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: > > You can't delete anything from a service name. Maybe we need to say tha= t > more explicitly. Right now the protocol doesn't allow a service to dele= te > itself; only to add itself. The assumption is that the service will not > know in advance that it is leaving the network, so service entries get > garbage collected, rather than being explicitly deleted. Compare to > DHCPRELEASE in the DHCP protocol, which is pretty useless. > > On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri wrote: > >> You might not need a new KEY record for the PTR but you may need to >> follow the instance of the PTR to a KEY record to make sure you have >> permission to delete the PTR record. >> >> Tom >> >> >> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >> >> Tim and I were talking and we were wondering if one client could delete >> the PTR record for a service instance that another client created? Seems >> like it=E2=80=99s not protected and could be a denial of service attack?= So you >> might need a KEY record the PTR record. >> >> Tom >> >> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >> >> Hm, you're right, that's never stated explicitly. >> >> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >> wrote: >> >>> I don=E2=80=99t see anywhere in the document where the anycast update m= ethod >>> relies on UDP. >>> >>> Tom >>> >>> >>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>> >>> Of course, you still have a very good point in that the anycast update >>> method relies on UDP, so sending the key multiple times isn't desirable= . >>> But I also don't see a way around this. We could have the server >>> replicate the key, I guess. >>> >>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>> wrote: >>> >>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>> possibility of off-network spoofing is eliminated=E2=80=9D. So requiri= ng TCP is >>>> already handled. >>>> >>>> Searching for _dns-update._udp. still seems odd but that=E2=80= =99s been >>>> going on for a while a presume. >>>> >>>> Tom >>>> >>>> >>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: >>>> >>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TC= P. So >>>> either you search for _dns-update._udp. and use TCP or you >>>> register _tcp. >>>> >>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP packe= t >>>> size larger than 512, you probably wouldn=E2=80=99t want to set it lar= ger than the >>>> MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records. >>>> >>>> Tom >>>> >>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: >>>> >>>> If you are adding more KEY records, you will certainly exceed the UDP >>>> update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe >>>> this should be restricted to TCP. >>>> The draft does mention searching for the update server using _dns-upda= te._udp.. >>>> But then it won=E2=80=99t be able to use UDP for updates. >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>> >>>> Tim pointed out that we need to protect the Service Instance Name as >>>> well as the Host Description with a KEY record, because FCFS naming ha= s to >>>> protect both the service description and the host description. Here = are >>>> the changes: >>>> >>>> >>>> https://github.com/StuartCheshire/draft-sctl-service-registration/comp= are/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157d= f8da85874597 >>>> >>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >>>> >>>>> The question of whether we update RFC6763 is basically "is there text >>>>> that is in RFC6763 that is no longer correct because of this document= ." I >>>>> think the answer is no. >>>>> >>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>> registration protocol as DNS Dynamic Update, should this document cl= aim it >>>>>> updates 6763? >>>>>> >>>>>> Thanks, >>>>>> Tom >>>>>> >>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>> >>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried t= o >>>>>> harmonize the document toward that=E2=80=94did I miss something? >>>>>> >>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>> Discovery? >>>>>>> >>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>> >>>>>>> Thanks, >>>>>>> Tom >>>>>>> >>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>> >>>>>>> BTW, the current version of the document on github now includes >>>>>>> fixes for all the points that have been raised other than the ones = I said I >>>>>>> wasn't going to fix: >>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote= : >>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = < >>>>>>>> toke@toke.dk> wrote: >>>>>>>> >>>>>>>>> Ted Lemon writes: >>>>>>>>> >>>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>>> device >>>>>>>>> that just wants to register its name but doesn't (currently, or >>>>>>>>> ever) >>>>>>>>> advertise any services... >>>>>>>>> >>>>>>>>> Good question. What does the working group think? :) >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> > --0000000000004336920571503775 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that=E2=80=99s the correct behavior.=C2=A0

On Wed, Jul 18,= 2018 at 9:30 PM Tom Pusateri <pus= ateri@bangj.com> wrote:
Yeah, that needs to be more explicit.=C2=A0

If you try to do a delete, does the server send REF= USED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:
You can't delet= e anything from a service name.=C2=A0 =C2=A0Maybe we need to say that more = explicitly.=C2=A0 =C2=A0Right now the protocol doesn't allow a service = to delete itself; only to add itself.=C2=A0 =C2=A0The assumption is that th= e service will not know in advance that it is leaving the network, so servi= ce entries get garbage collected, rather than being explicitly deleted.=C2= =A0 =C2=A0Compare to DHCPRELEASE in the DHCP protocol, which is pretty usel= ess.

On Wed,= Jul 18, 2018 at 7:40 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
You might not need a new KEY record for the= PTR but you may need to follow the instance of the PTR to a KEY record to = make sure you have permission to delete the PTR record.

To= m


On Jul 18, 2018, at 7:37 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Tim and I were talking and we were wondering if on= e client could delete the PTR record for a service instance that another cl= ient created? Seems like it=E2=80=99s not protected and could be a denial o= f service attack? So you might need a KEY record the PTR record.
=
Tom

On Jul 18, = 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right, that's never stated explicitly.

On Wed, Jul 18, 2018 at 12= :48 PM, Tom Pusateri <pusateri@bangj.com> wrote:
I don=E2=80=99t see anywhere in the document where the any= cast update method relies on UDP.

Tom


On J= ul 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of course, you still have a very good point= in that the anycast update method relies on UDP, so sending the key multip= le times isn't desirable.=C2=A0 =C2=A0But I also don't see a way ar= ound this.=C2=A0 =C2=A0We could have the server replicate the key, I guess.=

On Wed, Jul= 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wr= ote:
Just saw this in Section 2: "By requir= ing the use of TCP, the possibility of off-network spoofing is eliminated= =E2=80=9D. So requiring TCP is already handled.

Searchin= g for=C2=A0_dns-update._udp.<domain> still seems odd but that=E2=80= =99s been going on for a while a presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-upd= ate isn=E2=80=99t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you r= egister _tcp.

And while you could use an ED= NS(0) OPT RR to set the maximum UDP packet size larger than 512, you probab= ly wouldn=E2=80=99t want to set it larger than the MTU and 1480 isn=E2=80= =99t big enough for 3 KEYs plus other records.

Tom

On Jul 18, = 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If you are adding more KEY records, you will cert= ainly exceed the UDP update size of 512 bytes. The draft doesn=E2=80=99t me= ntion transport but maybe this should be restricted to TCP.
The draft d= oes mention searching for the update server using=C2=A0_dns-update._udp.<domain>. But then it won=E2=80=99t= be able to use UDP for updates.

Than= ks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon= <mellon@fugue.com= > wrote:

Tim pointed out that we need to protect the Service Insta= nce Name as well as the Host Description with a KEY record, because FCFS na= ming has to protect both the service description and the host description.= =C2=A0 =C2=A0Here are the changes:


=
On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mell= on@fugue.com> wrote:
The question of whether we update RFC6763 is basically "= is there text that is in RFC6763 that is no longer correct because of this = document."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusat= eri@bangj.com> wrote:
Ok, just che= cking. So given that 6763 semi-defines service registration protocol as DNS= Dynamic Update, should this document claim it updates 6763?

=
Thanks,
Tom

On Jul 16, 2018, a= t 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery.=C2=A0 =C2=A0= So I tried to harmonize the document toward that=E2=80=94did I miss somethi= ng?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
How is=C2=A0DNS-Bas= ed Service Discovery different from DNS Service Discovery?

Is this meant to distinguish from RFC 6763?
=C2=A0
Tha= nks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:
BTW, the curren= t version of the document on github now includes fixes for all the points t= hat have been raised other than the ones I said I wasn't going to fix:= =C2=A0https://github.com/StuartCheshire/draft-sctl-ser= vice-registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <= mellon@fugue.com&= gt; wrote:
On Mon, Jul 16, 2018 at = 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does= the working group think?=C2=A0 =C2=A0:)=C2=A0

=

_______= ________________________________________
dnssd mailing list=
dnssd@= ietf.org
https://www.ietf.org/mailman/listinfo/dnssd=

_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd maili= ng list
dnssd@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
<= /div>

= _______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


________________________________________= _______
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

=
--0000000000004336920571503775-- From nobody Wed Jul 18 19:07:35 2018 Return-Path: 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 4E305130E78 for ; Wed, 18 Jul 2018 19:07:34 -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 evzi_XD_dfTD for ; Wed, 18 Jul 2018 19:07:29 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 AF859126BED for ; Wed, 18 Jul 2018 19:07:29 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id q20-v6so7195066ith.0 for ; Wed, 18 Jul 2018 19:07:29 -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=p0qDwQXHgpM233FumdccgmrT8W8FDKBCsZ9X3ASEoSY=; b=PUKA2djQfPO0Gw5oKXWbk0FNB54KUbtMbv56obCh1vD3PbhBqS7kCPBD/qAKKVD0SP gyXvce6GpwKlRXg4gmQ7BnxgbJVADLBpFbd0OdpqbaZEQKC8E3d/rqiDgjJ0eYJQO8Vz 9YIcp1UOOUaG6KIBnHMafwOQqOdgx/1gEorX2eFvz2z8sgcnv1UX7LxC6OUyfR1GTmVH Og540huLx5rNqQDeRoVl23H7uTzTlF2MDGU8jVX2epQIrKp3jdWofdWatYvRct1QZ4US PCsNWHNe7US3pPkB2Fwd3KIBw5wdIjiYU7zPSz6edmxAuymI4Eqnitt+QNHxaO94QzS5 i0Ow== 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=p0qDwQXHgpM233FumdccgmrT8W8FDKBCsZ9X3ASEoSY=; b=KJlB3Cqfu+j3dvnSu1ZLUOR2DEb9jJY6Cu9LVvx0AV90TYre8ZC56zTuI/crCWQuFN jn9gnvXhQaRSLaVxFOnZ4wGYxTU5CzVEF5pCqq9/4yKQt6eEC93TKUWWsXLCld8LUKcW ZS9kgezKOPZyVFz6aBuVkexil+jdIaQhJMvQvl983Uoa9r1HKqhfeHa9zf9H7YNp9C5N 8A2J/WPkZdVP+JQL36SsqnWrC4dUqnn7rysBhC0TKXextZnenBjH6+P4vsifEjJZc0xO 4JaU7xblNLo5WSuD0uCequRk3k8+dpOMa8JZDjGuwufBEEfClp1+0piaFXVnkdFSEE3c LOTg== X-Gm-Message-State: AOUpUlEpuYyCZ+2BrkbbzhkrliBH3PJGo1MgmhpTGmganNFNDVCutbI0 49GermENZovIAwKMjs4sJTYo2NfmQum+FTfJOPixxA6L X-Google-Smtp-Source: AAOMgpe9l0G3lQlO+oglMnfAAZwTLb3YIhAalO7bhpdzoeHeeL5Qf8KqTQyZ9D2AJXqOVP8eYWYdBpLw8xehc5rpYzs= X-Received: by 2002:a02:1bdc:: with SMTP id 89-v6mr7612694jas.72.1531966048884; Wed, 18 Jul 2018 19:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 19:06:48 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> From: Ted Lemon Date: Wed, 18 Jul 2018 22:06:48 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000026f300057150a465" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 02:07:34 -0000 --00000000000026f300057150a465 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, I've pushed fixes for the last couple of issues you guys brought up. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for debate. https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce= 15160933b458a2da2346b6181ad89ed0ff1e11 On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: > Yes, that=E2=80=99s the correct behavior. > > On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote: > >> Yeah, that needs to be more explicit. >> >> If you try to do a delete, does the server send REFUSED? >> >> Thanks, >> Tom >> >> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >> >> You can't delete anything from a service name. Maybe we need to say >> that more explicitly. Right now the protocol doesn't allow a service t= o >> delete itself; only to add itself. The assumption is that the service >> will not know in advance that it is leaving the network, so service entr= ies >> get garbage collected, rather than being explicitly deleted. Compare t= o >> DHCPRELEASE in the DHCP protocol, which is pretty useless. >> >> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri wrote= : >> >>> You might not need a new KEY record for the PTR but you may need to >>> follow the instance of the PTR to a KEY record to make sure you have >>> permission to delete the PTR record. >>> >>> Tom >>> >>> >>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >>> >>> Tim and I were talking and we were wondering if one client could delete >>> the PTR record for a service instance that another client created? Seem= s >>> like it=E2=80=99s not protected and could be a denial of service attack= ? So you >>> might need a KEY record the PTR record. >>> >>> Tom >>> >>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>> >>> Hm, you're right, that's never stated explicitly. >>> >>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >>> wrote: >>> >>>> I don=E2=80=99t see anywhere in the document where the anycast update = method >>>> relies on UDP. >>>> >>>> Tom >>>> >>>> >>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>> >>>> Of course, you still have a very good point in that the anycast update >>>> method relies on UDP, so sending the key multiple times isn't desirabl= e. >>>> But I also don't see a way around this. We could have the server >>>> replicate the key, I guess. >>>> >>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>>> wrote: >>>> >>>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>>> possibility of off-network spoofing is eliminated=E2=80=9D. So requir= ing TCP is >>>>> already handled. >>>>> >>>>> Searching for _dns-update._udp. still seems odd but that=E2= =80=99s >>>>> been going on for a while a presume. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote= : >>>>> >>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for T= CP. So >>>>> either you search for _dns-update._udp. and use TCP or you >>>>> register _tcp. >>>>> >>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP >>>>> packet size larger than 512, you probably wouldn=E2=80=99t want to se= t it larger >>>>> than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records. >>>>> >>>>> Tom >>>>> >>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote= : >>>>> >>>>> If you are adding more KEY records, you will certainly exceed the UDP >>>>> update size of 512 bytes. The draft doesn=E2=80=99t mention transport= but maybe >>>>> this should be restricted to TCP. >>>>> The draft does mention searching for the update server using >>>>> _dns-update._udp.. But then it won=E2=80=99t be able to use U= DP for >>>>> updates. >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>> >>>>> Tim pointed out that we need to protect the Service Instance Name as >>>>> well as the Host Description with a KEY record, because FCFS naming h= as to >>>>> protect both the service description and the host description. Here= are >>>>> the changes: >>>>> >>>>> https://github.com/StuartCheshire/draft-sctl- >>>>> service-registration/compare/ae53618d8231733701ccdda4d33669 >>>>> 2a529c9f6b...5c85181881b84ed1132d544e157df8da85874597 >>>>> >>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >>>>> >>>>>> The question of whether we update RFC6763 is basically "is there tex= t >>>>>> that is in RFC6763 that is no longer correct because of this documen= t." I >>>>>> think the answer is no. >>>>>> >>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>>> registration protocol as DNS Dynamic Update, should this document c= laim it >>>>>>> updates 6763? >>>>>>> >>>>>>> Thanks, >>>>>>> Tom >>>>>>> >>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>>> >>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried >>>>>>> to harmonize the document toward that=E2=80=94did I miss something? >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>>> Discovery? >>>>>>>> >>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tom >>>>>>>> >>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>>> >>>>>>>> BTW, the current version of the document on github now includes >>>>>>>> fixes for all the points that have been raised other than the ones= I said I >>>>>>>> wasn't going to fix: https://github.com/StuartCheshire/draft-sctl- >>>>>>>> service-registration >>>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen= < >>>>>>>>> toke@toke.dk> wrote: >>>>>>>>> >>>>>>>>>> Ted Lemon writes: >>>>>>>>>> >>>>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>>>> device >>>>>>>>>> that just wants to register its name but doesn't (currently, or >>>>>>>>>> ever) >>>>>>>>>> advertise any services... >>>>>>>>>> >>>>>>>>>> Good question. What does the working group think? :) >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> >>> >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >>> >> --00000000000026f300057150a465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, I've pushed fixes for the last couple of issues = you guys brought up.=C2=A0 =C2=A0I used _dnssd-srp._tcp instead of _dns-upd= ate._udp, but that's up for debate.


On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, th= at=E2=80=99s the correct behavior.=C2=A0
<= div class=3D"h5">

On We= d, Jul 18, 2018 at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
Yeah, that needs = to be more explicit.=C2=A0

If you try to do a dele= te, does the server send REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, Te= d Lemon <mellon@fu= gue.com> wrote:

You can't delete anything from a service name.=C2=A0 =C2=A0May= be we need to say that more explicitly.=C2=A0 =C2=A0Right now the protocol = doesn't allow a service to delete itself; only to add itself.=C2=A0 =C2= =A0The assumption is that the service will not know in advance that it is l= eaving the network, so service entries get garbage collected, rather than b= eing explicitly deleted.=C2=A0 =C2=A0Compare to DHCPRELEASE in the DHCP pro= tocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <pusate= ri@bangj.com> wrote:
You might not ne= ed a new KEY record for the PTR but you may need to follow the instance of = the PTR to a KEY record to make sure you have permission to delete the PTR = record.

Tom

On Jul 18, 2018, at 7:37 PM, Tom = Pusateri <pusate= ri@bangj.com> wrote:

Tim and I were= talking and we were wondering if one client could delete the PTR record fo= r a service instance that another client created? Seems like it=E2=80=99s n= ot protected and could be a denial of service attack? So you might need a K= EY record the PTR record.

Tom

On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wro= te:

Hm, you're r= ight, that's never stated explicitly.
<= br>
On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusater= i <pusateri@bangj.com> wrote:
I = don=E2=80=99t see anywhere in the document where the anycast update method = relies on UDP.

Tom

=

On Jul 18, 2018, at 12:27 PM, Ted L= emon <mellon@fugue= .com> wrote:

=
Of course, you still have a very good point in that t= he anycast update method relies on UDP, so sending the key multiple times i= sn't desirable.=C2=A0 =C2=A0But I also don't see a way around this.= =C2=A0 =C2=A0We could have the server replicate the key, I guess.

On Wed, Jul 18, 2018 = at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the us= e of TCP, the possibility of off-network spoofing is eliminated=E2=80=9D. S= o requiring TCP is already handled.

Searching for=C2=A0_= dns-update._udp.<domain> still seems odd but that=E2=80=99s been goin= g on for a while a presume.

Tom


On Jul 18, 2018, at 12:15= PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update i= sn=E2=80=99t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you regist= er _tcp.

<= div>And while you could use an EDNS(0)= OPT RR to set the maximum UDP packet size larger than 512, you probably wo= uldn=E2=80=99t want to set it larger than the MTU and 1480 isn=E2=80=99t bi= g enough for 3 KEYs plus other records.

Tom

On Jul 18, 2018, a= t 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If you are adding more KEY record= s, you will certainly exceed the UDP update size of 512 bytes. The draft do= esn=E2=80=99t mention transport but maybe this should be restricted to TCP.=
The draft does mention searching for the update server using=C2=A0_dns-update._udp.<domain>. But = then it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, = at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim pointed out= that we need to protect the Service Instance Name as well as the Host Desc= ription with a KEY record, because FCFS naming has to protect both the serv= ice description and the host description.=C2=A0 =C2=A0Here are the changes:=


On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@f= ugue.com> wrote:
The question of whether we update RFC6763 is basically "is t= here text that is in RFC6763 that is no longer correct because of this docu= ment."=C2=A0 I think the answer is no.

On Mon, Jul 16, = 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-define= s service registration protocol as DNS Dynamic Update, should this document= claim it updates 6763?

Thanks,
Tom
=

On Jul 16, 2018, at 6:01 PM, Ted L= emon <mellon@fugue= .com> wrote:

The title of RFC 6763 is DNS-Based Service Discovery.=C2=A0 =C2= =A0So I tried to harmonize the document toward that=E2=80=94did I miss some= thing?

On Mo= n, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is=C2=A0DNS-= Based Service Discovery different from DNS Service Discovery?
<= div>
<= div>Is this meant to distinguish from RFC 6763?
=C2=A0
= Thanks,
Tom<= /span>

On Jul 16, 2018, at 5:46 PM, Te= d Lemon <mellon@fu= gue.com> wrote:

BTW, the current version of the document on github now includes fi= xes for all the points that have been raised other than the ones I said I w= asn't going to fix:=C2=A0https://github.com/S= tuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM,= Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <tok= e@toke.dk> wrote:
Ted Lemon <mell= on@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.= =C2=A0 =C2=A0What does the working group think?=C2=A0 =C2=A0:)=C2=A0=


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailma= n/listinfo/dnssd


_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



___________________________________= ____________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd



--00000000000026f300057150a465-- From nobody Wed Jul 18 19:17:57 2018 Return-Path: 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 34E2D130ED3 for ; Wed, 18 Jul 2018 19:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KrrDebdhldeZ for ; Wed, 18 Jul 2018 19:17:47 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3E9130FFA for ; Wed, 18 Jul 2018 19:17:47 -0700 (PDT) Received: from [25.56.120.46] (unknown [24.114.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E0776C93; Wed, 18 Jul 2018 22:15:54 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-510EEA27-D43D-4E2B-9644-A3DF19A918BF Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16A5327f) In-Reply-To: Date: Wed, 18 Jul 2018 22:17:42 -0400 Cc: dnssd Content-Transfer-Encoding: 7bit Message-Id: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> To: Ted Lemon Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 02:17:55 -0000 --Apple-Mail-510EEA27-D43D-4E2B-9644-A3DF19A918BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So if a device changes it=E2=80=99s name, the old one could be around for a w= hile along side the new name.=20 That might be confusing.=20 Tom > On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: >=20 > Okay, I've pushed fixes for the last couple of issues you guys brought up.= I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for deb= ate. >=20 > https://github.com/StuartCheshire/draft-sctl-service-registration/commit/c= e15160933b458a2da2346b6181ad89ed0ff1e11 >=20 >> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: >> Yes, that=E2=80=99s the correct behavior.=20 >>=20 >>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote:= >>> Yeah, that needs to be more explicit.=20 >>>=20 >>> If you try to do a delete, does the server send REFUSED? >>>=20 >>> Thanks, >>> Tom >>>=20 >>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>>>=20 >>>> You can't delete anything from a service name. Maybe we need to say t= hat more explicitly. Right now the protocol doesn't allow a service to del= ete itself; only to add itself. The assumption is that the service will no= t know in advance that it is leaving the network, so service entries get gar= bage collected, rather than being explicitly deleted. Compare to DHCPRELEA= SE in the DHCP protocol, which is pretty useless. >>>>=20 >>>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri wro= te: >>>>> You might not need a new KEY record for the PTR but you may need to fo= llow the instance of the PTR to a KEY record to make sure you have permissio= n to delete the PTR record. >>>>>=20 >>>>> Tom >>>>>=20 >>>>>=20 >>>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote:= >>>>>>=20 >>>>>> Tim and I were talking and we were wondering if one client could dele= te the PTR record for a service instance that another client created? Seems l= ike it=E2=80=99s not protected and could be a denial of service attack? So y= ou might need a KEY record the PTR record. >>>>>>=20 >>>>>> Tom >>>>>>=20 >>>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>>>>=20 >>>>>>> Hm, you're right, that's never stated explicitly. >>>>>>>=20 >>>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri w= rote: >>>>>>>> I don=E2=80=99t see anywhere in the document where the anycast upda= te method relies on UDP. >>>>>>>>=20 >>>>>>>> Tom >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>>>>>>=20 >>>>>>>>> Of course, you still have a very good point in that the anycast up= date method relies on UDP, so sending the key multiple times isn't desirable= . But I also don't see a way around this. We could have the server repli= cate the key, I guess. >>>>>>>>>=20 >>>>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri wrote: >>>>>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the pos= sibility of off-network spoofing is eliminated=E2=80=9D. So requiring TCP is= already handled. >>>>>>>>>>=20 >>>>>>>>>> Searching for _dns-update._udp. still seems odd but that=E2= =80=99s been going on for a while a presume. >>>>>>>>>>=20 >>>>>>>>>> Tom >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri w= rote: >>>>>>>>>>>=20 >>>>>>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned f= or TCP. So either you search for _dns-update._udp. and use TCP or yo= u register _tcp. >>>>>>>>>>>=20 >>>>>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP= packet size larger than 512, you probably wouldn=E2=80=99t want to set it l= arger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other r= ecords. >>>>>>>>>>>=20 >>>>>>>>>>> Tom >>>>>>>>>>>=20 >>>>>>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> If you are adding more KEY records, you will certainly exceed t= he UDP update size of 512 bytes. The draft doesn=E2=80=99t mention transport= but maybe this should be restricted to TCP. >>>>>>>>>>>> The draft does mention searching for the update server using _d= ns-update._udp.. But then it won=E2=80=99t be able to use UDP for up= dates. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tom >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrot= e: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Tim pointed out that we need to protect the Service Instance N= ame as well as the Host Description with a KEY record, because FCFS naming h= as to protect both the service description and the host description. Here a= re the changes: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registrat= ion/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d5= 44e157df8da85874597 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon = wrote: >>>>>>>>>>>>>> The question of whether we update RFC6763 is basically "is th= ere text that is in RFC6763 that is no longer correct because of this docume= nt." I think the answer is no. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote: >>>>>>>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service r= egistration protocol as DNS Dynamic Update, should this document claim it up= dates 6763? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon w= rote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I= tried to harmonize the document toward that=E2=80=94did I miss something? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote: >>>>>>>>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Serv= ice Discovery? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon = wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> BTW, the current version of the document on github now in= cludes fixes for all the points that have been raised other than the ones I s= aid I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-serv= ice-registration >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>>>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3= =B8rgensen wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Why can't it be just a Host Description? Might be usefu= l for a device >>>>>>>>>>>>>>>>>>>> that just wants to register its name but doesn't (curre= ntly, or ever) >>>>>>>>>>>>>>>>>>>> advertise any services... >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Good question. What does the working group think? :)= =20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dnssd mailing list >>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>=20 >>>>=20 >=20 --Apple-Mail-510EEA27-D43D-4E2B-9644-A3DF19A918BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
So if a device changes it=E2= =80=99s name, the old one could be around for a while along side the new nam= e. 

That might be confusing. 
<= br>
Tom

On Jul 18, 2018, at 10:06 PM, Ted Lemon <= mellon@fugue.com> wrote:

<= /div>
Okay, I've pushed fixes= for the last couple of issues you guys brought up.   I used _dnss= d-srp._tcp instead of _dns-update._udp, but that's up for debate.

On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <mellon@fugue= .com> wrote:
Yes, that=E2=80=99s the correct behavior. 

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
Yeah, that= needs to be more explicit. 

If you try to do a= delete, does the server send REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM,= Ted Lemon <mellon@= fugue.com> wrote:

You can't delete anything from a service name.   Maybe w= e need to say that more explicitly.   Right now the protocol doesn= 't allow a service to delete itself; only to add itself.   The ass= umption is that the service will not know in advance that it is leaving the n= etwork, so service entries get garbage collected, rather than being explicit= ly deleted.   Compare to DHCPRELEASE in the DHCP protocol, which i= s pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <pusateri@bangj.com&g= t; wrote:
You might not need a new KEY record fo= r the PTR but you may need to follow the instance of the PTR to a KEY record= to make sure you have permission to delete the PTR record.
=
Tom


On Jul 18, 2018, at 7:37 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Tim and I were talking and we were wondering if o= ne client could delete the PTR record for a service instance that another cl= ient created? Seems like it=E2=80=99s not protected and could be a denial of= service attack? So you might need a KEY record the PTR record.
Tom

On Jul 18, 201= 8, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

=
Hm, you're right, that's never stated explicitly.

On Wed, Jul 18, 2018 a= t 12:48 PM, Tom Pusateri <pusateri@bangj.com> wrote:
I don=E2=80=99t see anywhere in the document where the any= cast update method relies on UDP.

=
Tom=


On Jul 18, 2018, at 12= :27 PM, Ted Lemon <= mellon@fugue.com> wrote:

Of course, you still have a very good point i= n that the anycast update method relies on UDP, so sending the key multiple t= imes isn't desirable.   But I also don't see a way around this.&nb= sp;  We could have the server replicate the key, I guess.

On Wed, Jul 18, 2018 at 12= :25 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the p= ossibility of off-network spoofing is eliminated=E2=80=9D. So requiring TCP i= s already handled.

Searching for _dns-update._udp.&l= t;domain> still seems odd but that=E2=80=99s been going on for a while a p= resume.
Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com>= ; wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. S= o either you search for _dns-update._ud= p.<domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set the maximum UDP packe= t size larger than 512, you probably wouldn=E2=80=99t want to set it larger t= han the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records.=

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:=

=
If you= are adding more KEY records, you will certainly exceed the UDP update size o= f 512 bytes. The draft doesn=E2=80=99t mention transport but maybe this shou= ld be restricted to TCP.
The draft does mention searching for the update= server using _dns-update._udp.<= ;domain>. But then it won=E2=80=99t be able to use UDP for updates.<= /span>

= Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

T= im pointed out that we need to protect the Service Instance Name as well as t= he Host Description with a KEY record, because FCFS naming has to protect bo= th the service description and the host description.   Here are th= e changes:


=
On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@= fugue.com> wrote:
The question of whether we update RFC6763 is basically "is there t= ext that is in RFC6763 that is no longer correct because of this document."&= nbsp; I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, T= om Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service registration p= rotocol as DNS Dynamic Update, should this document claim it updates 6763?
Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 i= s DNS-Based Service Discovery.   So I tried to harmonize the docum= ent toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusate= ri <pusateri@bangj.com> wrote:
How is DNS-Based Service Discovery different from DNS= Service Discovery?

Is this meant to distinguish from RFC 67= 63?
 
Thanks,
Tom

On J= ul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document o= n github now includes fixes for all the points that have been raised other t= han the ones I said I wasn't going to fix: https://= github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2= 018 at 5:29 PM, Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3= =B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for a de= vice
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.  &n= bsp;What does the working group think?   :) 


________= _______________________________________
dnssd mailing l= ist
dnss= d@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
d= nssd mailing list
dns= sd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_________________________________= ______________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd


_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



____________________________________= ___________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/= dnssd



= --Apple-Mail-510EEA27-D43D-4E2B-9644-A3DF19A918BF-- From nobody Wed Jul 18 19:31:02 2018 Return-Path: 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 60402130E98 for ; Wed, 18 Jul 2018 19:30:59 -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 k87-Puqo9Y9J for ; Wed, 18 Jul 2018 19:30:55 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D31AB130E78 for ; Wed, 18 Jul 2018 19:30:54 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l7-v6so5834695ioj.1 for ; Wed, 18 Jul 2018 19:30:54 -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=vvyuz5Oi/O0OY8nObYXpVtFRxrpBnj0QvrZ7tKkl6M8=; b=RaetOSQI/O2a/Ns83bwONDarAvKnTMvJBTudVb3cOkjyH7sEINJFk+TzkUDN9jy0s4 TfPvFLKtbesh8yVrVhsLlCIOu/K3ZAzlAu/LafUBFPNOB150cTnlZCL/iO7UQWsM2Dbd /JvaaNxiDUIhyjRiCnmhABKhdU6AS8gFb+XNA0IGdDNMqgH0X67DOySfEik2i7Y8AT7e f86O/eGCqpUGusbw2I+Wv/N5z6plpbaXHgZHLofb/R6jjZAB3FTx7V07uSueyIe40Iu8 qsDKKOQczxqwSaBP9i9+WGYRLSolFZGv7NfXuIX6Setms0HkEVTnB94/yWCQhfgPD1hZ /pug== 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=vvyuz5Oi/O0OY8nObYXpVtFRxrpBnj0QvrZ7tKkl6M8=; b=Bd2IIYpDo7XjsgOwj9fEhzp7dstaQRwpXUYtljEhucUwcB0Yj01dBSmUTI/AARZGE7 BmxEJQzXSEHo9hEGW9HlWNFHgaro5jvvSespNMk4sOOfgxfeH8+U6/stEbjfNQbwGQxm ffKDG7d/lDv1FH0aHc+LdHXgVInEzm5/upwfeknRTSkLSJb/qFFMpejahR+vOY/pUukc jvBRZs3fvDVyd2hHqYvH7EZGe+QZIEU66fzoGwIVIg6ksmA2oyRJJwInHmoRzOQohXDD v79unPWjStTOUWXWUMR+IYvz5aJ1pkApBQhLH/bZVsfhQm+cE5JNlT2rNgRSy4ImV9FE pVuQ== X-Gm-Message-State: AOUpUlGBbsOnXajiNW5zWyDRQq3N3CeOxGYTw3VVT3dVlfru2B1n7GfV VhdXZH54khUeiV5uze0PyAw6mExz3hErif2S1ccdkQ== X-Google-Smtp-Source: AA+uWPyXHHMBMLMMEzl4M6bY8Uhy1r+I3Q0WXr1n452lNBRLqrdMxyJy8lkPdmQOZDapqJH9HGdTFeIAwZBTQ1GNh9s= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr7047541ioc.45.1531967454008; Wed, 18 Jul 2018 19:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 19:30:13 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> From: Ted Lemon Date: Wed, 18 Jul 2018 22:30:13 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000e77770057150f72e" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 02:31:00 -0000 --000000000000e77770057150f72e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Depends on how the name change happens, but sure. If a device has a name-change UI, it could use a very short update lease time, but the server might override it. I guess we could define an SRP delete message that deletes all or part of a registration. On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri wrote: > So if a device changes it=E2=80=99s name, the old one could be around for= a while > along side the new name. > > That might be confusing. > > Tom > > On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: > > Okay, I've pushed fixes for the last couple of issues you guys brought > up. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up f= or > debate. > > https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ > ce15160933b458a2da2346b6181ad89ed0ff1e11 > > On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: > >> Yes, that=E2=80=99s the correct behavior. >> >> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote: >> >>> Yeah, that needs to be more explicit. >>> >>> If you try to do a delete, does the server send REFUSED? >>> >>> Thanks, >>> Tom >>> >>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>> >>> You can't delete anything from a service name. Maybe we need to say >>> that more explicitly. Right now the protocol doesn't allow a service = to >>> delete itself; only to add itself. The assumption is that the service >>> will not know in advance that it is leaving the network, so service ent= ries >>> get garbage collected, rather than being explicitly deleted. Compare = to >>> DHCPRELEASE in the DHCP protocol, which is pretty useless. >>> >>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri >>> wrote: >>> >>>> You might not need a new KEY record for the PTR but you may need to >>>> follow the instance of the PTR to a KEY record to make sure you have >>>> permission to delete the PTR record. >>>> >>>> Tom >>>> >>>> >>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >>>> >>>> Tim and I were talking and we were wondering if one client could delet= e >>>> the PTR record for a service instance that another client created? See= ms >>>> like it=E2=80=99s not protected and could be a denial of service attac= k? So you >>>> might need a KEY record the PTR record. >>>> >>>> Tom >>>> >>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>> >>>> Hm, you're right, that's never stated explicitly. >>>> >>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >>>> wrote: >>>> >>>>> I don=E2=80=99t see anywhere in the document where the anycast update= method >>>>> relies on UDP. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>> >>>>> Of course, you still have a very good point in that the anycast updat= e >>>>> method relies on UDP, so sending the key multiple times isn't desirab= le. >>>>> But I also don't see a way around this. We could have the server >>>>> replicate the key, I guess. >>>>> >>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>>>> possibility of off-network spoofing is eliminated=E2=80=9D. So requi= ring TCP is >>>>>> already handled. >>>>>> >>>>>> Searching for _dns-update._udp. still seems odd but that=E2= =80=99s >>>>>> been going on for a while a presume. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for = TCP. So >>>>>> either you search for _dns-update._udp. and use TCP or you >>>>>> register _tcp. >>>>>> >>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP >>>>>> packet size larger than 512, you probably wouldn=E2=80=99t want to s= et it larger >>>>>> than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other= records. >>>>>> >>>>>> Tom >>>>>> >>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>> If you are adding more KEY records, you will certainly exceed the UD= P >>>>>> update size of 512 bytes. The draft doesn=E2=80=99t mention transpor= t but maybe >>>>>> this should be restricted to TCP. >>>>>> The draft does mention searching for the update server using >>>>>> _dns-update._udp.. But then it won=E2=80=99t be able to use = UDP for >>>>>> updates. >>>>>> >>>>>> Thanks, >>>>>> Tom >>>>>> >>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>>> >>>>>> Tim pointed out that we need to protect the Service Instance Name as >>>>>> well as the Host Description with a KEY record, because FCFS naming = has to >>>>>> protect both the service description and the host description. Her= e are >>>>>> the changes: >>>>>> >>>>>> https://github.com/StuartCheshire/draft-sctl-service- >>>>>> registration/compare/ae53618d8231733701ccdda4d336692a529c9f6 >>>>>> b...5c85181881b84ed1132d544e157df8da85874597 >>>>>> >>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >>>>>> >>>>>>> The question of whether we update RFC6763 is basically "is there >>>>>>> text that is in RFC6763 that is no longer correct because of this >>>>>>> document." I think the answer is no. >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>>>> registration protocol as DNS Dynamic Update, should this document = claim it >>>>>>>> updates 6763? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tom >>>>>>>> >>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>>>> >>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I tried >>>>>>>> to harmonize the document toward that=E2=80=94did I miss something= ? >>>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>>>> wrote: >>>>>>>> >>>>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>>>> Discovery? >>>>>>>>> >>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>>>> >>>>>>>>> BTW, the current version of the document on github now includes >>>>>>>>> fixes for all the points that have been raised other than the one= s I said I >>>>>>>>> wasn't going to fix: https://github.com/Stuart >>>>>>>>> Cheshire/draft-sctl-service-registration >>>>>>>>> >>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgense= n < >>>>>>>>>> toke@toke.dk> wrote: >>>>>>>>>> >>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>> >>>>>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>>>>> device >>>>>>>>>>> that just wants to register its name but doesn't (currently, or >>>>>>>>>>> ever) >>>>>>>>>>> advertise any services... >>>>>>>>>>> >>>>>>>>>>> Good question. What does the working group think? :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd >>>> >>>> >>>> >>> > --000000000000e77770057150f72e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Depends on how the name change happens, but sure.=C2=A0 = =C2=A0If a device has a name-change UI, it could use a very short update le= ase time, but the server might override it.=C2=A0 =C2=A0I guess we could de= fine an SRP delete message that deletes all or part of a registration.

On Wed, Jul 18, = 2018 at 10:17 PM, Tom Pusateri <pusateri@bangj.com> wrote:<= br>
So if a= device changes it=E2=80=99s name, the old one could be around for a while = along side the new name.=C2=A0

That might be confu= sing.=C2=A0

Tom

On Jul 18, = 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:

Okay, I've pushed fixes for the last co= uple of issues you guys brought up.=C2=A0 =C2=A0I used _dnssd-srp._tcp inst= ead of _dns-update._udp, but that's up for debate.

<= a href=3D"https://github.com/StuartCheshire/draft-sctl-service-registration= /commit/ce15160933b458a2da2346b6181ad89ed0ff1e11" target=3D"_blank">https:/= /github.com/StuartCheshire/draft-sctl-service-registration/commit= /ce15160933b458a2da2346b6181ad89ed0ff1e11

On Wed, Jul 18, 2018 = at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, that=E2=80=99s the correct= behavior.=C2=A0

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:<= br>
Y= eah, that needs to be more explicit.=C2=A0

If you = try to do a delete, does the server send REFUSED?

= Thanks,
Tom

On Jul 18, 2018= , at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a service name.= =C2=A0 =C2=A0Maybe we need to say that more explicitly.=C2=A0 =C2=A0Right n= ow the protocol doesn't allow a service to delete itself; only to add i= tself.=C2=A0 =C2=A0The assumption is that the service will not know in adva= nce that it is leaving the network, so service entries get garbage collecte= d, rather than being explicitly deleted.=C2=A0 =C2=A0Compare to DHCPRELEASE= in the DHCP protocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pu= sateri <pusateri@bangj.com> wrote:
You might not need a new KEY record for the PTR but you may need to fol= low the instance of the PTR to a KEY record to make sure you have permissio= n to delete the PTR record.

=
Tom
<= div class=3D"m_917584537540808375m_8604855592838733868m_565778382887669563h= 5">

On Jul 18, 2018, at 7:37 PM,= Tom Pusateri <p= usateri@bangj.com> wrote:

Tim and I were talking and we were wondering if one client could= delete the PTR record for a service instance that another client created? = Seems like it=E2=80=99s not protected and could be a denial of service atta= ck? So you might need a KEY record the PTR record.

Tom

On Jul 18, 2018, at 1:08 = PM, Ted Lemon <mel= lon@fugue.com> wrote:

Hm, you're right, that's never stated = explicitly.

= On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com>= ; wrote:
I don=E2=80=99t see anywhere in = the document where the anycast update method relies on UDP.

Tom
=


On Ju= l 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of = course, you still have a very good point in that the anycast update method = relies on UDP, so sending the key multiple times isn't desirable.=C2=A0= =C2=A0But I also don't see a way around this.=C2=A0 =C2=A0We could hav= e the server replicate the key, I guess.
On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri= <pusateri@bangj.com> wrote:
Jus= t saw this in Section 2: "By requiring the use of TCP, the possibility= of off-network spoofing is eliminated=E2=80=9D. So requiring TCP is alread= y handled.

Searching for=C2=A0_dns-update._udp.<domai= n> still seems odd but that=E2=80=99s been going on for a while a presum= e.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Looking in the IANA registry, dns-update isn=E2=80=99t assigne= d for TCP. So either you search for _d= ns-update._udp.<domain> and use TCP or you register _tcp.
=
And while you could use an EDNS(0) OPT RR to set the m= aximum UDP packet size larger than 512, you probably wouldn=E2=80=99t want = to set it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs = plus other records.
<= br>
Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusa= teri <pusateri@b= angj.com> wrote:

If you are adding more KEY records,= you will certainly exceed the UDP update size of 512 bytes. The draft does= n=E2=80=99t mention transport but maybe this should be restricted to TCP.The draft does mention searching for the update server using=C2=A0_dns-update._udp.<domain>. But th= en it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at= 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim pointed out that we need to protect the Service Instance Name as wel= l as the Host Description with a KEY record, because FCFS naming has to pro= tect both the service description and the host description.=C2=A0 =C2=A0Her= e are the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted Le= mon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basical= ly "is there text that is in RFC6763 that is no longer correct because= of this document."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom P= usateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service registrat= ion protocol as DNS Dynamic Update, should this document claim it updates 6= 763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted = Lemon <mellon@fugu= e.com> wrote:

The title of RFC 6763 is DNS-Based Service= Discovery.=C2=A0 =C2=A0So I tried to harmonize the document toward that=E2= =80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@= bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery different from DNS Service Di= scovery?

Is this meant to distinguish from RFC 6763?
=
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version= of the document on github now includes fixes for all the points that have = been raised other than the ones I said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-service-= registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <= mellon@fugue.com&= gt; wrote:
On Mon, Jul 16, 2018 at = 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0What does the working group think?=C2=A0 = =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailma= n/listinfo/dnssd


_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



___________________________________= ____________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd




--000000000000e77770057150f72e-- From nobody Wed Jul 18 19:47:51 2018 Return-Path: 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 7DC1B130ED7 for ; Wed, 18 Jul 2018 19:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=timwattenberg-de.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 Z7I2_0HnsspP for ; Wed, 18 Jul 2018 19:47:44 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 46481130E91 for ; Wed, 18 Jul 2018 19:47:44 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id 94-v6so2906050ple.12 for ; Wed, 18 Jul 2018 19:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timwattenberg-de.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JjKsQrw3GQRYdgVUekHsQfopEEuiXQp969PmClJwK28=; b=NlUMW0vRUzt1/tacnm26shxPSodNx7gXaR9/bZybpwcgwmIEj/6Wj3JeuUm71TxqJ4 mnLevXdhDEVtBoJ473ZfaTVrLsy8eWIHfuN4odFvITEtqAOkF6DEry8rnQyLM8hiB+RN UV8kbym/MlVeKzTTmB+EDj7vXx1k8mxyyNJt012hrRFNDosNv1CAa9UXGqpeZVAP2hpn PT1ND1GZPg+pcYVoSo/Lb2pB0QnOhAM5a+a4Y3YVsiZCy30S2cCJsjhfwrl3ElaDR8PF Vu0k4csHMWmiT9jollT44hbV13YlulDNLMZdEPO6KLOaoj2sm8wNrp52fMKH7g9PyOah fPyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JjKsQrw3GQRYdgVUekHsQfopEEuiXQp969PmClJwK28=; b=SAClV/K/n1qYCe06w7VxsE7UoaP9fnWrIW61Gnh9gcCOsonzDY3BW0x309LvrYW/Mq titwJsHR/l7sPPp+H0v3OjRjPY+7RunHaIuYsYIsiB3zzLAo7ny4HjgBpOTfw4NnxKzd uQbT0IBh1nW6ZpeVOZucc4EXbA+iSdUq0OMAS7GWagltd8WEiC6UbCWnzHj5iWzTUilN kcJ6+poNvEYPNEWbxQC/T+uCkQmU1nKaFV7qoepM2z6gEjBuFK5Htm0KcqpEmzu1ryM8 lDGFLSa0OxJ/ZFDLQ+wYewh57iW0p96p7GPHRqVPV27e87BR3LMJk7pi+SaCEJEWGCME 7kAw== X-Gm-Message-State: AOUpUlGNC0XH3IECYYdMoKK5eTVSVcXtOuvuRV8/fohEU+TR+Vgmi9HD LWEyWfGoGQP2WhzrOd5cMxbs5gk0JGo= X-Google-Smtp-Source: AAOMgpdhOQ4w0yqFe0NTZMQKMWyipP+3tapZw+4Ef8/xw01EAYYngZ4bQCyVyi6v5j7KkNYrswIrTA== X-Received: by 2002:a17:902:b48c:: with SMTP id y12-v6mr8162362plr.97.1531968463389; Wed, 18 Jul 2018 19:47:43 -0700 (PDT) Received: from [26.248.77.247] (mfa2736d0.tmodns.net. [208.54.39.250]) by smtp.gmail.com with ESMTPSA id h6-v6sm6441645pfn.80.2018.07.18.19.47.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 19:47:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-52C6A070-4FAD-42B7-8673-B162AD048B67 Mime-Version: 1.0 (1.0) From: Tim Wattenberg X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Wed, 18 Jul 2018 22:47:38 -0400 Cc: Tom Pusateri , dnssd Content-Transfer-Encoding: 7bit Message-Id: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> To: Ted Lemon Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 02:47:50 -0000 --Apple-Mail-52C6A070-4FAD-42B7-8673-B162AD048B67 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, you said that deleting a service instance is not covered by the draft, I can= see how a short lease time could mimic that functionality.=20 However if we allow any DNS update operation on the PTRs besides adding a re= cord, wouldn=E2=80=99t that actually still require checking the =E2=80=9Cown= ership=E2=80=9D? Otherwise a service could update another services=E2=80=99 l= ease time and by that =E2=80=9Cdelete=E2=80=9D the other service.=20 > On 18. Jul 2018, at 22:30, Ted Lemon wrote: >=20 > Depends on how the name change happens, but sure. If a device has a name= -change UI, it could use a very short update lease time, but the server migh= t override it. I guess we could define an SRP delete message that deletes a= ll or part of a registration. >=20 >> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri wrote= : >> So if a device changes it=E2=80=99s name, the old one could be around for= a while along side the new name.=20 >>=20 >> That might be confusing.=20 >>=20 >> Tom >>=20 >>> On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: >>>=20 >>> Okay, I've pushed fixes for the last couple of issues you guys brought u= p. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for d= ebate. >>>=20 >>> https://github.com/StuartCheshire/draft-sctl-service-registration/commit= /ce15160933b458a2da2346b6181ad89ed0ff1e11 >>>=20 >>>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: >>>> Yes, that=E2=80=99s the correct behavior.=20 >>>>=20 >>>>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrot= e: >>>>> Yeah, that needs to be more explicit.=20 >>>>>=20 >>>>> If you try to do a delete, does the server send REFUSED? >>>>>=20 >>>>> Thanks, >>>>> Tom >>>>>=20 >>>>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>>>>>=20 >>>>>> You can't delete anything from a service name. Maybe we need to say= that more explicitly. Right now the protocol doesn't allow a service to d= elete itself; only to add itself. The assumption is that the service will n= ot know in advance that it is leaving the network, so service entries get ga= rbage collected, rather than being explicitly deleted. Compare to DHCPRELE= ASE in the DHCP protocol, which is pretty useless. >>>>>>=20 >>>>>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri w= rote: >>>>>>> You might not need a new KEY record for the PTR but you may need to f= ollow the instance of the PTR to a KEY record to make sure you have permissi= on to delete the PTR record. >>>>>>>=20 >>>>>>> Tom >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrot= e: >>>>>>>>=20 >>>>>>>> Tim and I were talking and we were wondering if one client could de= lete the PTR record for a service instance that another client created? Seem= s like it=E2=80=99s not protected and could be a denial of service attack? S= o you might need a KEY record the PTR record. >>>>>>>>=20 >>>>>>>> Tom >>>>>>>>=20 >>>>>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>>>>>>=20 >>>>>>>>> Hm, you're right, that's never stated explicitly. >>>>>>>>>=20 >>>>>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri wrote: >>>>>>>>>> I don=E2=80=99t see anywhere in the document where the anycast up= date method relies on UDP. >>>>>>>>>>=20 >>>>>>>>>> Tom >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote= : >>>>>>>>>>>=20 >>>>>>>>>>> Of course, you still have a very good point in that the anycast u= pdate method relies on UDP, so sending the key multiple times isn't desirabl= e. But I also don't see a way around this. We could have the server repl= icate the key, I guess. >>>>>>>>>>>=20 >>>>>>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri wrote: >>>>>>>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the p= ossibility of off-network spoofing is eliminated=E2=80=9D. So requiring TCP i= s already handled. >>>>>>>>>>>>=20 >>>>>>>>>>>> Searching for _dns-update._udp. still seems odd but tha= t=E2=80=99s been going on for a while a presume. >>>>>>>>>>>>=20 >>>>>>>>>>>> Tom >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigne= d for TCP. So either you search for _dns-update._udp. and use TCP or= you register _tcp. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum U= DP packet size larger than 512, you probably wouldn=E2=80=99t want to set it= larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other= records. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Tom >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If you are adding more KEY records, you will certainly exceed= the UDP update size of 512 bytes. The draft doesn=E2=80=99t mention transpo= rt but maybe this should be restricted to TCP. >>>>>>>>>>>>>> The draft does mention searching for the update server using _= dns-update._udp.. But then it won=E2=80=99t be able to use UDP for u= pdates. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wr= ote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Tim pointed out that we need to protect the Service Instance= Name as well as the Host Description with a KEY record, because FCFS naming= has to protect both the service description and the host description. Her= e are the changes: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registr= ation/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132= d544e157df8da85874597 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote: >>>>>>>>>>>>>>>> The question of whether we update RFC6763 is basically "is t= here text that is in RFC6763 that is no longer correct because of this docum= ent." I think the answer is no. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri wrote: >>>>>>>>>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service= registration protocol as DNS Dynamic Update, should this document claim it u= pdates 6763? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon = wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. S= o I tried to harmonize the document toward that=E2=80=94did I miss something= ? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri wrote: >>>>>>>>>>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Se= rvice Discovery? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Tom >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> BTW, the current version of the document on github now i= ncludes fixes for all the points that have been raised other than the ones I= said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-se= rvice-registration >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon wrote: >>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3= =B8rgensen wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Why can't it be just a Host Description? Might be use= ful for a device >>>>>>>>>>>>>>>>>>>>>> that just wants to register its name but doesn't (cur= rently, or ever) >>>>>>>>>>>>>>>>>>>>>> advertise any services... >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Good question. What does the working group think? := )=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dnssd mailing list >>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>=20 >>>>>>=20 >>>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail-52C6A070-4FAD-42B7-8673-B162AD048B67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted,
you said that deleting a service i= nstance is not covered by the draft, I can see how a short lease time could m= imic that functionality. 

However if we allow a= ny DNS update operation on the PTRs besides adding a record, wouldn=E2=80=99= t that actually still require checking the =E2=80=9Cownership=E2=80=9D? Othe= rwise a service could update another services=E2=80=99 lease time and by tha= t =E2=80=9Cdelete=E2=80=9D the other service. 

On 18= . Jul 2018, at 22:30, Ted Lemon <mell= on@fugue.com> wrote:

Depends on how the name change happens, but sure.   I= f a device has a name-change UI, it could use a very short update lease time= , but the server might override it.   I guess we could define an S= RP delete message that deletes all or part of a registration.

On Wed, Jul 18, 2018 at 10:= 17 PM, Tom Pusateri <pusateri@bangj.com> wrote:
So if a device changes= it=E2=80=99s name, the old one could be around for a while along side the n= ew name. 

That might be confusing. 
=

Tom
=

On Jul 18, 2018, at 10:06 PM, T= ed Lemon <mellon@fu= gue.com> wrote:

Okay, I've pushed fixes for the last couple of issues you guys brought= up.   I used _dnssd-srp._tcp instead of _dns-update._udp, but tha= t's up for debate.


On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon &l= t;mellon@fugue.com= > wrote:
Ye= s, that=E2=80=99s the correct behavior. 

On Wed, Jul 18, 2018 at 9:30 PM Tom Pu= sateri <pusateri@= bangj.com> wrote:
Yeah, that needs to be more explicit. 
=
If you try to do a delete, does the server send REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a s= ervice name.   Maybe we need to say that more explicitly.  &n= bsp;Right now the protocol doesn't allow a service to delete itself; only to= add itself.   The assumption is that the service will not know in= advance that it is leaving the network, so service entries get garbage coll= ected, rather than being explicitly deleted.   Compare to DHCPRELE= ASE in the DHCP protocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom P= usateri <pusateri@bangj.com> wrote:
You m= ight not need a new KEY record for the PTR but you may need to follow the in= stance of the PTR to a KEY record to make sure you have permission to delete= the PTR record.

Tom


=
On Jul 18, 2018, at 7:37 PM, Tom Pusateri <= ;pusateri@bangj.com<= /a>> wrote:

Tim and I w= ere talking and we were wondering if one client could delete the PTR record f= or a service instance that another client created? Seems like it=E2=80=99s n= ot protected and could be a denial of service attack? So you might need a KE= Y record the PTR record.

Tom

On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:<= /div>
Hm= , you're right, that's never stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pus= ateri <pusateri@bangj.com> wrote:
I= don=E2=80=99t see anywhere in the document where the anycast update method r= elies on UDP.

=
Tom


On Jul 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:
<= div dir=3D"ltr">Of course, you still have a very good point in that the anyc= ast update method relies on UDP, so sending the key multiple times isn't des= irable.   But I also don't see a way around this.   We c= ould have the server replicate the key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pu= sateri <pusateri@bangj.com> wrote:
= Just saw this in Section 2: "By requiring the use of TCP, the possibility of= off-network spoofing is eliminated=E2=80=9D. So requiring TCP is already ha= ndled.

Searching for _dns-update._udp.<domain>= still seems odd but that=E2=80=99s been going on for a while a presume.

Tom


On J= ul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

=
Lookin= g in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. So either= you search for _dns-update._udp.<do= main> and use TCP or you register _tcp.

An= d while you could use an EDNS(0) OPT RR to set the maximum UDP packet size l= arger than 512, you probably wouldn=E2=80=99t want to set it larger than the= MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records.=

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:
If you are adding more KEY records, you will certainly exceed the UDP u= pdate size of 512 bytes. The draft doesn=E2=80=99t mention transport but may= be this should be restricted to TCP.
The draft does mention searching fo= r the update server using _dns-upd= ate._udp.<domain>. But then it won=E2=80=99t be able to use UDP f= or updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim pointed out that we need to protect the Se= rvice Instance Name as well as the Host Description with a KEY record, becau= se FCFS naming has to protect both the service description and the host desc= ription.   Here are the changes:


On Mon, Jul 16, 2018 a= t 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6= 763 is basically "is there text that is in RFC6763 that is no longer correct= because of this document."  I think the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusate= ri <pusateri@bangj.com> wrote:
Ok, j= ust checking. So given that 6763 semi-defines service registration protocol a= s DNS Dynamic Update, should this document claim it updates 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:<= /div>
The title of RFC 6763 is DNS-Based Service Discovery.   S= o I tried to harmonize the document toward that=E2=80=94did I miss something= ?

On Mon, Jul= 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote= :
How= is DNS-Based Serv= ice Discovery different from DNS Service Discovery?

Is this m= eant to distinguish from RFC 6763?
 
Thanks,
<= div>Tom

On Jul 16, 2018, at 5:46 PM, T= ed Lemon <mellon@fu= gue.com> wrote:

BTW, the current version of the document on github now includes fixes f= or all the points that have been raised other than the ones I said I wasn't g= oing to fix: https://github.com/StuartCheshire= /draft-sctl-service-registration
On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mell= on@fugue.com> wrote:
On Mon, J= ul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen &= lt;toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> wr= ites:

Why can't it be just a Host Description? Might be useful for a de= vice
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

<= span style=3D"font-size:small;background-color:rgb(255,255,255);text-decorat= ion-style:initial;text-decoration-color:initial;float:none;display:inline">G= ood question.   What does the working group think?   :)<= /span> 


________= _______________________________________
dnssd mailing l= ist
dnss= d@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
d= nssd mailing list
dns= sd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_________________________________= ______________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/list= info/dnssd


_______________________________________________
dnssd mailing listdnssd@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/dnssd



____________________________________= ___________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/= dnssd




____________________= ___________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mai= lman/listinfo/dnssd
= --Apple-Mail-52C6A070-4FAD-42B7-8673-B162AD048B67-- From nobody Wed Jul 18 20:35:08 2018 Return-Path: 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 47E29130ED3 for ; Wed, 18 Jul 2018 20:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 P322Sf2I6CtT for ; Wed, 18 Jul 2018 20:35:00 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343B0130E9F for ; Wed, 18 Jul 2018 20:35:00 -0700 (PDT) Received: from dhcp-9194.meeting.ietf.org (dhcp-9194.meeting.ietf.org [31.133.145.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 6AECACA6; Wed, 18 Jul 2018 23:33:07 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C5FD61FC-25F8-405E-A87F-34E53F39BF57" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 23:34:57 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 03:35:05 -0000 --Apple-Mail=_C5FD61FC-25F8-405E-A87F-34E53F39BF57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking of name changes, you may need to handle name collision in a = special way. Since devices can=E2=80=99t see other devices names, they = can=E2=80=99t easily create unique names. So if there are 10 light bulbs = from the same vendor all starting to register the instance name =E2=80=9Cl= ight bulb=E2=80=9D, the first will succeed and the others get YXDOMAIN. = The second one will realize the name is taken but not know how to = necessarily create a new name that is unique. The tenth light bulb might = go through 9 iterations before generating a unique name. The traditional = name collision avoidance mechanism with mDNS of incrementing a numerical = suffix doesn=E2=80=99t work very well when you don=E2=80=99t know how = many there are. It might be better to suggest a random suffix instead of a numerical one = or some other mechanism of generating unique names from the beginning. = But then they won=E2=80=99t look human readable so I don=E2=80=99t know = if that is a consideration. Thanks, Tom > On Jul 18, 2018, at 10:30 PM, Ted Lemon wrote: >=20 > Depends on how the name change happens, but sure. If a device has a = name-change UI, it could use a very short update lease time, but the = server might override it. I guess we could define an SRP delete = message that deletes all or part of a registration. >=20 > On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri > wrote: > So if a device changes it=E2=80=99s name, the old one could be around = for a while along side the new name.=20 >=20 > That might be confusing.=20 >=20 > Tom >=20 > On Jul 18, 2018, at 10:06 PM, Ted Lemon > wrote: >=20 >> Okay, I've pushed fixes for the last couple of issues you guys = brought up. I used _dnssd-srp._tcp instead of _dns-update._udp, but = that's up for debate. >>=20 >> = https://github.com/StuartCheshire/draft-sctl-service-registration/commit/c= e15160933b458a2da2346b6181ad89ed0ff1e11 = >>=20 >> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon > wrote: >> Yes, that=E2=80=99s the correct behavior.=20 >>=20 >> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri > wrote: >> Yeah, that needs to be more explicit.=20 >>=20 >> If you try to do a delete, does the server send REFUSED? >>=20 >> Thanks, >> Tom >>=20 >> On Jul 18, 2018, at 8:27 PM, Ted Lemon > wrote: >>=20 >>> You can't delete anything from a service name. Maybe we need to = say that more explicitly. Right now the protocol doesn't allow a = service to delete itself; only to add itself. The assumption is that = the service will not know in advance that it is leaving the network, so = service entries get garbage collected, rather than being explicitly = deleted. Compare to DHCPRELEASE in the DHCP protocol, which is pretty = useless. >>>=20 >>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri > wrote: >>> You might not need a new KEY record for the PTR but you may need to = follow the instance of the PTR to a KEY record to make sure you have = permission to delete the PTR record. >>>=20 >>> Tom >>>=20 >>>=20 >>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri > wrote: >>>>=20 >>>> Tim and I were talking and we were wondering if one client could = delete the PTR record for a service instance that another client = created? Seems like it=E2=80=99s not protected and could be a denial of = service attack? So you might need a KEY record the PTR record. >>>>=20 >>>> Tom >>>>=20 >>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon > wrote: >>>>>=20 >>>>> Hm, you're right, that's never stated explicitly. >>>>>=20 >>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri > wrote: >>>>> I don=E2=80=99t see anywhere in the document where the anycast = update method relies on UDP. >>>>>=20 >>>>> Tom >>>>>=20 >>>>>=20 >>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon > wrote: >>>>>>=20 >>>>>> Of course, you still have a very good point in that the anycast = update method relies on UDP, so sending the key multiple times isn't = desirable. But I also don't see a way around this. We could have the = server replicate the key, I guess. >>>>>>=20 >>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = > wrote: >>>>>> Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. >>>>>>=20 >>>>>> Searching for _dns-update._udp. still seems odd but = that=E2=80=99s been going on for a while a presume. >>>>>>=20 >>>>>> Tom >>>>>>=20 >>>>>>=20 >>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri > wrote: >>>>>>>=20 >>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned = for TCP. So either you search for _dns-update._udp. and use TCP = or you register _tcp. >>>>>>>=20 >>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP = packet size larger than 512, you probably wouldn=E2=80=99t want to set = it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus = other records. >>>>>>>=20 >>>>>>> Tom >>>>>>>=20 >>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>>>>>>>=20 >>>>>>>> If you are adding more KEY records, you will certainly exceed = the UDP update size of 512 bytes. The draft doesn=E2=80=99t mention = transport but maybe this should be restricted to TCP. >>>>>>>> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Tom >>>>>>>>=20 >>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>>>>>>>=20 >>>>>>>>> Tim pointed out that we need to protect the Service Instance = Name as well as the Host Description with a KEY record, because FCFS = naming has to protect both the service description and the host = description. Here are the changes: >>>>>>>>>=20 >>>>>>>>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>>>>>>>=20 >>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>>>>>>>> The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>>>>>>>=20 >>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri = > wrote: >>>>>>>>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>>=20 >>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>>>>>>>=20 >>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I = tried to harmonize the document toward that=E2=80=94did I miss = something? >>>>>>>>>>=20 >>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri = > wrote: >>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service = Discovery? >>>>>>>>>>=20 >>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>> =20 >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>>=20 >>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>>>>>>>=20 >>>>>>>>>>> BTW, the current version of the document on github now = includes fixes for all the points that have been raised other than the = ones I said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon > wrote: >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgen= sen > wrote: >>>>>>>>>>> Ted Lemon > = writes: >>>>>>>>>>>=20 >>>>>>>>>>> Why can't it be just a Host Description? Might be useful for = a device >>>>>>>>>>> that just wants to register its name but doesn't (currently, = or ever) >>>>>>>>>>> advertise any services... >>>>>>>>>>>=20 >>>>>>>>>>> Good question. What does the working group think? :)=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dnssd mailing list >>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnssd mailing list >>>> dnssd@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_C5FD61FC-25F8-405E-A87F-34E53F39BF57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Speaking of name changes, you may need to handle name = collision in a special way. Since devices can=E2=80=99t see other = devices names, they can=E2=80=99t easily create unique names. So if = there are 10 light bulbs from the same vendor all starting to register = the instance name =E2=80=9Clight bulb=E2=80=9D, the first will succeed = and the others get YXDOMAIN. The second one will realize the name is = taken but not know how to necessarily create a new name that is unique. = The tenth light bulb might go through 9 iterations before generating a = unique name. The traditional name collision avoidance mechanism with = mDNS of incrementing a numerical suffix doesn=E2=80=99t work very well = when you don=E2=80=99t know how many there are.

It might be better to suggest a random = suffix instead of a numerical one or some other mechanism of generating = unique names from the beginning. But then they won=E2=80=99t look human = readable so I don=E2=80=99t know if that is a consideration.

Thanks,
Tom



On Jul 18, 2018, at 10:30 PM, Ted Lemon = <mellon@fugue.com> wrote:

Depends on how the name change happens, but sure.  =  If a device has a name-change UI, it could use a very short update = lease time, but the server might override it.   I guess we = could define an SRP delete message that deletes all or part of a = registration.

On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
So if a device changes = it=E2=80=99s name, the old one could be around for a while along side = the new name. 

That might be confusing. 

Tom

On Jul 18, = 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:

Okay, I've pushed fixes for the = last couple of issues you guys brought up.   I used = _dnssd-srp._tcp instead of _dns-update._udp, but that's up for = debate.

https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11

On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, that=E2=80=99s the correct = behavior. 

On Wed, Jul 18, 2018 = at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
Yeah, that needs to be = more explicit. 

If you try to do a delete, does the server send = REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, = Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a service = name.   Maybe we need to say that more explicitly.  =  Right now the protocol doesn't allow a service to delete itself; = only to add itself.   The assumption is that the service will = not know in advance that it is leaving the network, so service entries = get garbage collected, rather than being explicitly deleted.  =  Compare to DHCPRELEASE in the DHCP protocol, which is pretty = useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
You= might not need a new KEY record for the PTR but you may need to follow = the instance of the PTR to a KEY record to make sure you have permission = to delete the PTR record.

Tom
=

On Jul 18, 2018, at 7:37 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

Tim and I were talking and we were wondering = if one client could delete the PTR record for a service instance that = another client created? Seems like it=E2=80=99s not protected and could = be a denial of service attack? So you might need a KEY record the PTR = record.

Tom

On Jul 18, 2018, at 1:08 PM, = Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right, that's never stated = explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
I = don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP.

Tom


On Jul = 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of course, you still have a very = good point in that the anycast update method relies on UDP, so sending = the key multiple times isn't desirable.   But I also don't see = a way around this.   We could have the server replicate the = key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled.

Searching for _dns-update._udp.<domain> still = seems odd but that=E2=80=99s been going on for a while a = presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> = and use TCP or you register _tcp.

And while = you could use an EDNS(0) OPT RR to set the maximum UDP packet size = larger than 512, you probably wouldn=E2=80=99t want to set it larger = than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for = updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon = <mellon@fugue.com> wrote:

Tim pointed = out that we need to protect the Service Instance Name as well as the = Host Description with a KEY record, because FCFS naming has to protect = both the service description and the host description.   Here = are the changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, = Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, = Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is = DNS-Based Service Discovery.   So I tried to harmonize the = document toward that=E2=80=94did I miss something?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul = 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the = document on github now includes fixes for all the points that have been = raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd




_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_C5FD61FC-25F8-405E-A87F-34E53F39BF57-- From nobody Thu Jul 19 04:32:55 2018 Return-Path: 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 DBA18130F47 for ; Thu, 19 Jul 2018 04:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zrEyYTF569B0 for ; Thu, 19 Jul 2018 04:32:45 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8148E130F04 for ; Thu, 19 Jul 2018 04:32:44 -0700 (PDT) Received: from dhcp-9194.meeting.ietf.org (dhcp-9194.meeting.ietf.org [31.133.145.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5DF23D22; Thu, 19 Jul 2018 07:30:50 -0400 (EDT) From: Tom Pusateri Message-Id: <4C40C3A6-5871-4F44-8351-20948F5C5958@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8A119AA3-2541-4ACD-8D38-23EF5F39175B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 07:32:41 -0400 In-Reply-To: Cc: dnssd To: Ted Lemon References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 11:32:53 -0000 --Apple-Mail=_8A119AA3-2541-4ACD-8D38-23EF5F39175B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And I think this is a general problem to solve for unicast updates, not = necessarily a SRP thing. For instance, while the discovery proxy separates IP subnets which a = unique subdomain to avoid collision, using regular unicast update to a = discovery proxy doesn=E2=80=99t know about IP subnet subdomains and uses = a shared namespace. The unicast name collision problem exists there too. I haven=E2=80=99t read the mDNS relay spec in detail enough to know if = it collapses the namespace or abides by the IP subnet subdomain separate = namespaces. But this may be something Stuart already solved. I=E2=80=99m just not = aware of the solution. Thanks, Tom > On Jul 18, 2018, at 11:34 PM, Tom Pusateri wrote: >=20 > Speaking of name changes, you may need to handle name collision in a = special way. Since devices can=E2=80=99t see other devices names, they = can=E2=80=99t easily create unique names. So if there are 10 light bulbs = from the same vendor all starting to register the instance name =E2=80=9Cl= ight bulb=E2=80=9D, the first will succeed and the others get YXDOMAIN. = The second one will realize the name is taken but not know how to = necessarily create a new name that is unique. The tenth light bulb might = go through 9 iterations before generating a unique name. The traditional = name collision avoidance mechanism with mDNS of incrementing a numerical = suffix doesn=E2=80=99t work very well when you don=E2=80=99t know how = many there are. >=20 > It might be better to suggest a random suffix instead of a numerical = one or some other mechanism of generating unique names from the = beginning. But then they won=E2=80=99t look human readable so I don=E2=80=99= t know if that is a consideration. >=20 > Thanks, > Tom >=20 >=20 >=20 >> On Jul 18, 2018, at 10:30 PM, Ted Lemon > wrote: >>=20 >> Depends on how the name change happens, but sure. If a device has a = name-change UI, it could use a very short update lease time, but the = server might override it. I guess we could define an SRP delete = message that deletes all or part of a registration. >>=20 >> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri > wrote: >> So if a device changes it=E2=80=99s name, the old one could be around = for a while along side the new name.=20 >>=20 >> That might be confusing.=20 >>=20 >> Tom >>=20 >> On Jul 18, 2018, at 10:06 PM, Ted Lemon > wrote: >>=20 >>> Okay, I've pushed fixes for the last couple of issues you guys = brought up. I used _dnssd-srp._tcp instead of _dns-update._udp, but = that's up for debate. >>>=20 >>> = https://github.com/StuartCheshire/draft-sctl-service-registration/commit/c= e15160933b458a2da2346b6181ad89ed0ff1e11 = >>>=20 >>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon > wrote: >>> Yes, that=E2=80=99s the correct behavior.=20 >>>=20 >>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri > wrote: >>> Yeah, that needs to be more explicit.=20 >>>=20 >>> If you try to do a delete, does the server send REFUSED? >>>=20 >>> Thanks, >>> Tom >>>=20 >>> On Jul 18, 2018, at 8:27 PM, Ted Lemon > wrote: >>>=20 >>>> You can't delete anything from a service name. Maybe we need to = say that more explicitly. Right now the protocol doesn't allow a = service to delete itself; only to add itself. The assumption is that = the service will not know in advance that it is leaving the network, so = service entries get garbage collected, rather than being explicitly = deleted. Compare to DHCPRELEASE in the DHCP protocol, which is pretty = useless. >>>>=20 >>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri > wrote: >>>> You might not need a new KEY record for the PTR but you may need to = follow the instance of the PTR to a KEY record to make sure you have = permission to delete the PTR record. >>>>=20 >>>> Tom >>>>=20 >>>>=20 >>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri > wrote: >>>>>=20 >>>>> Tim and I were talking and we were wondering if one client could = delete the PTR record for a service instance that another client = created? Seems like it=E2=80=99s not protected and could be a denial of = service attack? So you might need a KEY record the PTR record. >>>>>=20 >>>>> Tom >>>>>=20 >>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon > wrote: >>>>>>=20 >>>>>> Hm, you're right, that's never stated explicitly. >>>>>>=20 >>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri = > wrote: >>>>>> I don=E2=80=99t see anywhere in the document where the anycast = update method relies on UDP. >>>>>>=20 >>>>>> Tom >>>>>>=20 >>>>>>=20 >>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon > wrote: >>>>>>>=20 >>>>>>> Of course, you still have a very good point in that the anycast = update method relies on UDP, so sending the key multiple times isn't = desirable. But I also don't see a way around this. We could have the = server replicate the key, I guess. >>>>>>>=20 >>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = > wrote: >>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled. >>>>>>>=20 >>>>>>> Searching for _dns-update._udp. still seems odd but = that=E2=80=99s been going on for a while a presume. >>>>>>>=20 >>>>>>> Tom >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri > wrote: >>>>>>>>=20 >>>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned = for TCP. So either you search for _dns-update._udp. and use TCP = or you register _tcp. >>>>>>>>=20 >>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum = UDP packet size larger than 512, you probably wouldn=E2=80=99t want to = set it larger than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs = plus other records. >>>>>>>>=20 >>>>>>>> Tom >>>>>>>>=20 >>>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri > wrote: >>>>>>>>>=20 >>>>>>>>> If you are adding more KEY records, you will certainly exceed = the UDP update size of 512 bytes. The draft doesn=E2=80=99t mention = transport but maybe this should be restricted to TCP. >>>>>>>>> The draft does mention searching for the update server using = _dns-update._udp.. But then it won=E2=80=99t be able to use UDP = for updates. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>>=20 >>>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon > wrote: >>>>>>>>>>=20 >>>>>>>>>> Tim pointed out that we need to protect the Service Instance = Name as well as the Host Description with a KEY record, because FCFS = naming has to protect both the service description and the host = description. Here are the changes: >>>>>>>>>>=20 >>>>>>>>>> = https://github.com/StuartCheshire/draft-sctl-service-registration/compare/= ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8d= a85874597 = >>>>>>>>>>=20 >>>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon > wrote: >>>>>>>>>> The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document." I think the answer is no. >>>>>>>>>>=20 >>>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri = > wrote: >>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service = registration protocol as DNS Dynamic Update, should this document claim = it updates 6763? >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>>=20 >>>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I = tried to harmonize the document toward that=E2=80=94did I miss = something? >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri = > wrote: >>>>>>>>>>> How is DNS-Based Service Discovery different from DNS = Service Discovery? >>>>>>>>>>>=20 >>>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>>> =20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Tom >>>>>>>>>>>=20 >>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> BTW, the current version of the document on github now = includes fixes for all the points that have been raised other than the = ones I said I wasn't going to fix: = https://github.com/StuartCheshire/draft-sctl-service-registration = >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon = > wrote: >>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rge= nsen > wrote: >>>>>>>>>>>> Ted Lemon > = writes: >>>>>>>>>>>>=20 >>>>>>>>>>>> Why can't it be just a Host Description? Might be useful = for a device >>>>>>>>>>>> that just wants to register its name but doesn't = (currently, or ever) >>>>>>>>>>>> advertise any services... >>>>>>>>>>>>=20 >>>>>>>>>>>> Good question. What does the working group think? :)=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> dnssd mailing list >>>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dnssd mailing list >>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd = >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_8A119AA3-2541-4ACD-8D38-23EF5F39175B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = I think this is a general problem to solve for unicast updates, not = necessarily a SRP thing.

For instance, while the discovery proxy separates IP subnets = which a unique subdomain to avoid collision, using regular unicast = update to a discovery proxy doesn=E2=80=99t know about IP subnet = subdomains and uses a shared namespace. The unicast name collision = problem exists there too.

I haven=E2=80=99t read the mDNS relay spec in detail enough = to know if it collapses the namespace or abides by the IP subnet = subdomain separate namespaces.

But this may be something Stuart = already solved. I=E2=80=99m just not aware of the solution.

Thanks,
Tom


On Jul = 18, 2018, at 11:34 PM, Tom Pusateri <pusateri@bangj.com> = wrote:

Speaking of name = changes, you may need to handle name collision in a special way. Since = devices can=E2=80=99t see other devices names, they can=E2=80=99t easily = create unique names. So if there are 10 light bulbs from the same vendor = all starting to register the instance name =E2=80=9Clight bulb=E2=80=9D, = the first will succeed and the others get YXDOMAIN. The second one will = realize the name is taken but not know how to necessarily create a new = name that is unique. The tenth light bulb might go through 9 iterations = before generating a unique name. The traditional name collision = avoidance mechanism with mDNS of incrementing a numerical suffix = doesn=E2=80=99t work very well when you don=E2=80=99t know how many = there are.

It might = be better to suggest a random suffix instead of a numerical one or some = other mechanism of generating unique names from the beginning. But then = they won=E2=80=99t look human readable so I don=E2=80=99t know if that = is a consideration.

Thanks,
Tom



On Jul = 18, 2018, at 10:30 PM, Ted Lemon <mellon@fugue.com> wrote:

Depends on how the name change happens, but sure.  =  If a device has a name-change UI, it could use a very short update = lease time, but the server might override it.   I guess we = could define an SRP delete message that deletes all or part of a = registration.

On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
So if a device changes = it=E2=80=99s name, the old one could be around for a while along side = the new name. 

That might be confusing. 

Tom

On Jul 18, = 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:

Okay, I've pushed fixes for the = last couple of issues you guys brought up.   I used = _dnssd-srp._tcp instead of _dns-update._udp, but that's up for = debate.

https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11

On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, that=E2=80=99s the correct = behavior. 

On Wed, Jul 18, 2018 = at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
Yeah, that needs to be = more explicit. 

If you try to do a delete, does the server send = REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, = Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a service = name.   Maybe we need to say that more explicitly.  =  Right now the protocol doesn't allow a service to delete itself; = only to add itself.   The assumption is that the service will = not know in advance that it is leaving the network, so service entries = get garbage collected, rather than being explicitly deleted.  =  Compare to DHCPRELEASE in the DHCP protocol, which is pretty = useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
You= might not need a new KEY record for the PTR but you may need to follow = the instance of the PTR to a KEY record to make sure you have permission = to delete the PTR record.

Tom
=

On Jul 18, 2018, at 7:37 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

Tim and I were talking and we were wondering = if one client could delete the PTR record for a service instance that = another client created? Seems like it=E2=80=99s not protected and could = be a denial of service attack? So you might need a KEY record the PTR = record.

Tom

On Jul 18, 2018, at 1:08 PM, = Ted Lemon <mellon@fugue.com> wrote:

Hm, you're right, that's never stated = explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
I = don=E2=80=99t see anywhere in the document where the anycast update = method relies on UDP.

Tom


On Jul = 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of course, you still have a very = good point in that the anycast update method relies on UDP, so sending = the key multiple times isn't desirable.   But I also don't see = a way around this.   We could have the server replicate the = key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri = <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the = possibility of off-network spoofing is eliminated=E2=80=9D. So requiring = TCP is already handled.

Searching for _dns-update._udp.<domain> still = seems odd but that=E2=80=99s been going on for a while a = presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Looking in the IANA registry, dns-update isn=E2=80=99t = assigned for TCP. So either you search for _dns-update._udp.<domain> = and use TCP or you register _tcp.

And while = you could use an EDNS(0) OPT RR to set the maximum UDP packet size = larger than 512, you probably wouldn=E2=80=99t want to set it larger = than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other = records.

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If = you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport = but maybe this should be restricted to TCP.
The draft = does mention searching for the update server using _dns-update._udp.<domain>. But then it won=E2=80=99t be able to use UDP for = updates.

Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon = <mellon@fugue.com> wrote:

Tim pointed = out that we need to protect the Service Instance Name as well as the = Host Description with a KEY record, because FCFS naming has to protect = both the service description and the host description.   Here = are the changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically "is = there text that is in RFC6763 that is no longer correct because of this = document."  I think the answer is no.

On Mon, = Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok,= just checking. So given that 6763 semi-defines service registration = protocol as DNS Dynamic Update, should this document claim it updates = 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, = Ted Lemon <mellon@fugue.com> wrote:

The title of RFC 6763 is = DNS-Based Service Discovery.   So I tried to harmonize the = document toward that=E2=80=94did I miss something?

On Mon, = Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is DNS-Based = Service Discovery different from DNS Service Discovery?

Is this meant to = distinguish from RFC 6763?
 
Thanks,
Tom

On Jul = 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the = document on github now includes fixes for all the points that have been = raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, 2018 at 5:29 PM, = Ted Lemon <mellon@fugue.com> wrote:
On Mon, = Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be = useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

Good question.   What does the working group = think?   :) 


_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd




_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_8A119AA3-2541-4ACD-8D38-23EF5F39175B-- From nobody Thu Jul 19 04:51:52 2018 Return-Path: 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 7DAD9131058 for ; Thu, 19 Jul 2018 04:51:39 -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 Aivl7UADpSjf for ; Thu, 19 Jul 2018 04:51:36 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 212B7131093 for ; Thu, 19 Jul 2018 04:51:36 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id q19-v6so6802648ioh.11 for ; Thu, 19 Jul 2018 04:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pz8fSjzyPrigB4Q6wg75Ob6zai+oJ1MU2IcbHborFz8=; b=NVktB/G5syMN6ATrxpl9XLimC5NiAxD9uKjVOikSyi4T5GWJPiDk5uv6mY4JECu8Uz QjTOCs0jjWJpSP+FW1TtYH8cLPK8MsIj7c8flHU/+Bw8KzDcqV31F5IaH3YljCM3YnvX +S58wfcji6rQI5NzIS7ge1DsiPNRNxIJ9dJ+AQbNNye83r/ZcIY0e2P2rzb1X6IGKjX8 uY9hZOF1cmHTuvcAlOSq7s7J8+QeQ9Vh5sh5Rtyz4AstoTdYK7eV08YfWXaxqkeltEE0 MP3Sla+zwrS4NDtDyBRdA4J9jFpDJdkVY8D1upeqgyFsy30l3OnATpYDtPOVukxbIYgE K++A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pz8fSjzyPrigB4Q6wg75Ob6zai+oJ1MU2IcbHborFz8=; b=gSUOgX0vPIbA/6kOhq5j4O9T5lmvqTBwzXK9g02OZYIaHY0wpRPIAvwZ3hkBd/eVud Uy+Lfa56mLyW7TIveZlaAuiWb/RpvKQCLiOMmvhXb4ZYRuPRLzrqjpbq1+/ulSiULOaB f49UzUAwuvu7m3jpUoKefGgHQYL+n7YNKPbYJ6rXdgcR0Ub0mVVsDvLFiMvkjHH1HBGg AIUxYYpObzkjr6txxfuq/OV5jdRa73d0heuDRBpjtVQKpggbxzr1ny1xg4W21GPIZho9 UNIJ1uWefMeuq8sxdZeSdq8nlGYlDkZQeO69K/kJsvVhEGTJhl+t71HKJHl/yG9awI7V mG2Q== X-Gm-Message-State: AOUpUlGJM4H4GT+2dVJoNaFUQwKKH6/phfjIPhvykPTiMgNGidHn52jX /MFcyPegckYeH2dH/t9SVsZoz3U0lRKE7uZKvtzu5YDXK48= X-Google-Smtp-Source: AA+uWPydU20lw48lyLhVQbeAF7sHh/16bngVxMj7OCEgSVGgG6Bkl9i+uzKQK58O8xEUUWmaBkM2b50Mipv2fKA/oHg= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr8186840ioc.45.1532001095421; Thu, 19 Jul 2018 04:51:35 -0700 (PDT) MIME-Version: 1.0 References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> In-Reply-To: From: Ted Lemon Date: Thu, 19 Jul 2018 07:51:24 -0400 Message-ID: To: Tim Wattenberg Cc: Tom Pusateri , dnssd Content-Type: multipart/alternative; boundary="00000000000016b390057158cd30" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 11:51:49 -0000 --00000000000016b390057158cd30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the way this would work is that you would have to delete your ptr record and at least the SRV and TXT records on the service instance name it points to. You would sign this with the KEY that is on the service instance name. This could be authenticated using that key. On Wed, Jul 18, 2018 at 10:47 PM Tim Wattenberg wrote: > Ted, > you said that deleting a service instance is not covered by the draft, I > can see how a short lease time could mimic that functionality. > > However if we allow any DNS update operation on the PTRs besides adding a > record, wouldn=E2=80=99t that actually still require checking the =E2=80= =9Cownership=E2=80=9D? > Otherwise a service could update another services=E2=80=99 lease time and= by that > =E2=80=9Cdelete=E2=80=9D the other service. > > On 18. Jul 2018, at 22:30, Ted Lemon wrote: > > Depends on how the name change happens, but sure. If a device has a > name-change UI, it could use a very short update lease time, but the serv= er > might override it. I guess we could define an SRP delete message that > deletes all or part of a registration. > > On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri wrote= : > >> So if a device changes it=E2=80=99s name, the old one could be around fo= r a while >> along side the new name. >> >> That might be confusing. >> >> Tom >> >> On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: >> >> Okay, I've pushed fixes for the last couple of issues you guys brought >> up. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up = for >> debate. >> >> >> https://github.com/StuartCheshire/draft-sctl-service-registration/commit= /ce15160933b458a2da2346b6181ad89ed0ff1e11 >> >> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: >> >>> Yes, that=E2=80=99s the correct behavior. >>> >>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote= : >>> >>>> Yeah, that needs to be more explicit. >>>> >>>> If you try to do a delete, does the server send REFUSED? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>>> >>>> You can't delete anything from a service name. Maybe we need to say >>>> that more explicitly. Right now the protocol doesn't allow a service= to >>>> delete itself; only to add itself. The assumption is that the servic= e >>>> will not know in advance that it is leaving the network, so service en= tries >>>> get garbage collected, rather than being explicitly deleted. Compare= to >>>> DHCPRELEASE in the DHCP protocol, which is pretty useless. >>>> >>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri >>>> wrote: >>>> >>>>> You might not need a new KEY record for the PTR but you may need to >>>>> follow the instance of the PTR to a KEY record to make sure you have >>>>> permission to delete the PTR record. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >>>>> >>>>> Tim and I were talking and we were wondering if one client could >>>>> delete the PTR record for a service instance that another client crea= ted? >>>>> Seems like it=E2=80=99s not protected and could be a denial of servic= e attack? So >>>>> you might need a KEY record the PTR record. >>>>> >>>>> Tom >>>>> >>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>> >>>>> Hm, you're right, that's never stated explicitly. >>>>> >>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> I don=E2=80=99t see anywhere in the document where the anycast updat= e method >>>>>> relies on UDP. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>>> >>>>>> Of course, you still have a very good point in that the anycast >>>>>> update method relies on UDP, so sending the key multiple times isn't >>>>>> desirable. But I also don't see a way around this. We could have= the >>>>>> server replicate the key, I guess. >>>>>> >>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>>>>> possibility of off-network spoofing is eliminated=E2=80=9D. So requ= iring TCP is >>>>>>> already handled. >>>>>>> >>>>>>> Searching for _dns-update._udp. still seems odd but that=E2= =80=99s >>>>>>> been going on for a while a presume. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for= TCP. So >>>>>>> either you search for _dns-update._udp. and use TCP or you >>>>>>> register _tcp. >>>>>>> >>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP >>>>>>> packet size larger than 512, you probably wouldn=E2=80=99t want to = set it larger >>>>>>> than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus othe= r records. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>> If you are adding more KEY records, you will certainly exceed the >>>>>>> UDP update size of 512 bytes. The draft doesn=E2=80=99t mention tra= nsport but maybe >>>>>>> this should be restricted to TCP. >>>>>>> The draft does mention searching for the update server using _dns-u= pdate._udp.. >>>>>>> But then it won=E2=80=99t be able to use UDP for updates. >>>>>>> >>>>>>> Thanks, >>>>>>> Tom >>>>>>> >>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>>>> >>>>>>> Tim pointed out that we need to protect the Service Instance Name a= s >>>>>>> well as the Host Description with a KEY record, because FCFS naming= has to >>>>>>> protect both the service description and the host description. He= re are >>>>>>> the changes: >>>>>>> >>>>>>> >>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration/c= ompare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e1= 57df8da85874597 >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote= : >>>>>>> >>>>>>>> The question of whether we update RFC6763 is basically "is there >>>>>>>> text that is in RFC6763 that is no longer correct because of this >>>>>>>> document." I think the answer is no. >>>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>>>>> registration protocol as DNS Dynamic Update, should this document= claim it >>>>>>>>> updates 6763? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>>>>> >>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I trie= d >>>>>>>>> to harmonize the document toward that=E2=80=94did I miss somethin= g? >>>>>>>>> >>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>>>>> Discovery? >>>>>>>>>> >>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>>>>> >>>>>>>>>> BTW, the current version of the document on github now includes >>>>>>>>>> fixes for all the points that have been raised other than the on= es I said I >>>>>>>>>> wasn't going to fix: >>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registratio= n >>>>>>>>>> >>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgens= en < >>>>>>>>>>> toke@toke.dk> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>> >>>>>>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>>>>>> device >>>>>>>>>>>> that just wants to register its name but doesn't (currently, o= r >>>>>>>>>>>> ever) >>>>>>>>>>>> advertise any services... >>>>>>>>>>>> >>>>>>>>>>>> Good question. What does the working group think? :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> >>>> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --00000000000016b390057158cd30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the way this would work is that you would have = to delete your ptr =C2=A0record and at least the SRV and TXT records on the= service instance name it points to. You would sign this with the KEY that = is on the service instance name. This could be authenticated using that key= .=C2=A0

On = Wed, Jul 18, 2018 at 10:47 PM Tim Wattenberg <mail@timwattenberg.de> wrote:
Ted,
you said that deleting a servic= e instance is not covered by the draft, I can see how a short lease time co= uld mimic that functionality.=C2=A0

However if we = allow any DNS update operation on the PTRs besides adding a record, wouldn= =E2=80=99t that actually still require checking the =E2=80=9Cownership=E2= =80=9D? Otherwise a service could update another services=E2=80=99 lease ti= me and by that =E2=80=9Cdelete=E2=80=9D the other service.=C2=A0

On 18. Jul 2018, at 22:30, Ted Lemon <<= a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@fugue.com&g= t; wrote:

Depe= nds on how the name change happens, but sure.=C2=A0 =C2=A0If a device has a= name-change UI, it could use a very short update lease time, but the serve= r might override it.=C2=A0 =C2=A0I guess we could define an SRP delete mess= age that deletes all or part of a registration.

On Wed, Jul 18, 2018 at 10:17 PM, Tom P= usateri <pusateri@bangj.com> wrote:
So if a device changes it= =E2=80=99s name, the old one could be around for a while along side the new= name.=C2=A0

That might be confusing.=C2=A0
<= span class=3D"m_5566832441292515403HOEnZb">
Tom

On Jul 18, 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:

=
Okay, I've pushed= fixes for the last couple of issues you guys brought up.=C2=A0 =C2=A0I use= d _dnssd-srp._tcp instead of _dns-update._udp, but that's up for debate= .


On Wed, Jul 18, 201= 8 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, that=E2=80=99s the corre= ct behavior.=C2=A0

On Wed, Jul 18, 2018= at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
Yeah, that needs to be more ex= plicit.=C2=A0

If you try to do a delete, does the = server send REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, Ted Lemon <<= a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@fugue.com&g= t; wrote:

You = can't delete anything from a service name.=C2=A0 =C2=A0Maybe we need to= say that more explicitly.=C2=A0 =C2=A0Right now the protocol doesn't a= llow a service to delete itself; only to add itself.=C2=A0 =C2=A0The assump= tion is that the service will not know in advance that it is leaving the ne= twork, so service entries get garbage collected, rather than being explicit= ly deleted.=C2=A0 =C2=A0Compare to DHCPRELEASE in the DHCP protocol, which = is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <= pusateri@bangj.com<= /a>> wrote:
You might not need a new KEY = record for the PTR but you may need to follow the instance of the PTR to a = KEY record to make sure you have permission to delete the PTR record.

Tom


Tim and I wer= e talking and we were wondering if one client could delete the PTR record f= or a service instance that another client created? Seems like it=E2=80=99s = not protected and could be a denial of service attack? So you might need a = KEY record the PTR record.

Tom

On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wr= ote:

Hm, you're right, that's never stated exp= licitly.

On = Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
I don=E2=80=99t see anywhere in t= he document where the anycast update method relies on UDP.

<= /font>
Tom


On Jul 18, 2018, a= t 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of course, you still have a very good point in that the anycast update= method relies on UDP, so sending the key multiple times isn't desirabl= e.=C2=A0 =C2=A0But I also don't see a way around this.=C2=A0 =C2=A0We c= ould have the server replicate the key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom = Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: "By requiring the use of TCP, the p= ossibility of off-network spoofing is eliminated=E2=80=9D. So requiring TCP= is already handled.

Searching for=C2=A0_dns-update._udp= .<domain> still seems odd but that=E2=80=99s been going on for a whil= e a presume.

= <= font color=3D"#888888">Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:
=
Looking in the IANA registry, dns-update is= n=E2=80=99t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you registe= r _tcp.

And while you could use an EDNS(0) = OPT RR to set the maximum UDP packet size larger than 512, you probably wou= ldn=E2=80=99t want to set it larger than the MTU and 1480 isn=E2=80=99t big= enough for 3 KEYs plus other records.

Tom

On Jul 18, 2018, at= 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:

If you are adding more KEY records, you will certainly exceed the UDP = update size of 512 bytes. The draft doesn=E2=80=99t mention transport but m= aybe this should be restricted to TCP.
The draft does mention searching= for the update server using=C2=A0_dns= -update._udp.<domain>. But then it won=E2=80=99t be able to use UDP f= or updates.

Thanks,
= Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:
=
Tim pointed out = that we need to protect the Service Instance Name as well as the Host Descr= iption with a KEY record, because FCFS naming has to protect both the servi= ce description and the host description.=C2=A0 =C2=A0Here are the changes:<= div>

On Mon, = Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:<= br>
The question of wheth= er we update RFC6763 is basically "is there text that is in RFC6763 th= at is no longer correct because of this document."=C2=A0 I think the a= nswer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pus= ateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service registration p= rotocol as DNS Dynamic Update, should this document claim it updates 6763?<= div>
Thanks,
Tom

On Jul 16, 2018, = at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:

The t= itle of RFC 6763 is DNS-Based Service Discovery.=C2=A0 =C2=A0So I tried to = harmonize the document toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 a= t 5:59 PM, Tom Pusateri <pusateri@bangj.com> wrote:
How is=C2= =A0DNS-Based Service D= iscovery different from DNS Service Discovery?

Is this mea= nt to distinguish from RFC 6763?
=C2=A0
Thanks,
Tom

On Ju= l 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of the document= on github now includes fixes for all the points that have been raised othe= r than the ones I said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-service-registration

On Mon, Jul 16, = 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland= -J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

<= /blockquote>
Good question.=C2=A0 =C2=A0What does the working = group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing list=
dnssd@= ietf.org
https://www.ietf.org/mailman/listinfo/dnssd=

_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd maili= ng list
dnssd@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
=

_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


________________________________________= _______
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

=


___________________= ____________________________
dnssd mailing list
<= span>dnssd@ietf.org=
https://www.ietf.org/mailman/listinfo/dnssd
<= /div>
--00000000000016b390057158cd30-- From nobody Thu Jul 19 04:55:34 2018 Return-Path: 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 57030130DEC for ; Thu, 19 Jul 2018 04:55:29 -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 FLqDJkMwwaPg for ; Thu, 19 Jul 2018 04:55:24 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 11BAE130DD8 for ; Thu, 19 Jul 2018 04:55:24 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id d70-v6so1845795ith.1 for ; Thu, 19 Jul 2018 04:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m9SVvXhBeo4Restad0dzbiQ8QSxC9XQwS/4BmVGUoXE=; b=olyj1CqYhO9Hwgw4bP8A1EDU7HenD4LOuIo2lMgyTXucrJ7l3wrplNwzdI7Up+awzc D6Ng3ThghDcCbKJs0TR0nT/JRFnSxLaLKQcWyoHnfJ6B25eiF35xt3i7NZPtcWEyDu1g UQHhq+jWpElJM9ggBWT3EOuqmT4FX+TtRGbziyQ4SBRZe1GK1PkNKLRdU5193b2wObL6 l3NjnQD2ny/Ey5yRUDemsOxvZs2aNC3NHMLN+ouXQjDhr4BRTiVeQd83kP+V3rh0jQyo 16iFTmozbGIMp5MePbkYoFSA3Jum2jrR9g41a5mjGIQsENtzKqeywlgAQneGxE50IooU R+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m9SVvXhBeo4Restad0dzbiQ8QSxC9XQwS/4BmVGUoXE=; b=lhX05S5/hZywPSZ0yTNKHcQeli+FFzHzlTBcRUQgEiLs3JZa64LapTERYbvTVYDroV r5oNM+hcCikO4CAdqsERJdPgAzqpBgP8MxEwHVNJy6L6MTCP0SL6Iv8RpwKV/PRKM0Ib 16BgUDp5J3gpRfx5eNnUKsCd61jz5+K8vL2dSS7oDUr2PkXx6C9Rs98lVGJTn3PeDHv5 eIAH8XlAZund8cZlg9cl5X3lBhh6SynvjuVmrAodFoIkgLr1OGJ9SFDUNZqi70fV8sHs abibWows66tPnntf8i3pOAEMLQ09Xz+2OsEGJPuWp7OiaG1RKp7y15aUJ2CpHnL8fQ09 4enA== X-Gm-Message-State: AOUpUlEGIcYKE+TBsgyk3F/4DkjB5vNsPQObKagNPAilRzLgVzDN0Ae+ wpH933u+WWUGcPr2QSD5y9ZBbMV+ezMCwRcw+TCVpOspkWI= X-Google-Smtp-Source: AAOMgpd3JObzbpyCy+ZVqqTzMBdYwNp6LRxfL9V8MZuWgR2HBniZ9IOp6MeiwEQOoZdNX9ihqTo8AkfLqAtzSeaf6d0= X-Received: by 2002:a02:b70b:: with SMTP id g11-v6mr9340729jam.34.1532001323235; Thu, 19 Jul 2018 04:55:23 -0700 (PDT) MIME-Version: 1.0 References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> <4C40C3A6-5871-4F44-8351-20948F5C5958@bangj.com> In-Reply-To: <4C40C3A6-5871-4F44-8351-20948F5C5958@bangj.com> From: Ted Lemon Date: Thu, 19 Jul 2018 07:55:12 -0400 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000aada41057158da8d" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 11:55:30 -0000 --000000000000aada41057158da8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The service registration domain is its own domain, not one of th link domains. Disambiguation is done in the UI. If there are two services in two different domains with the same name otherwise, these would appear in the UI with the same name, annotated with the link name. SRP names would follow the same convention. I think this is talked about in the service discovery broker document. On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri wrote: > And I think this is a general problem to solve for unicast updates, not > necessarily a SRP thing. > > For instance, while the discovery proxy separates IP subnets which a > unique subdomain to avoid collision, using regular unicast update to a > discovery proxy doesn=E2=80=99t know about IP subnet subdomains and uses = a shared > namespace. The unicast name collision problem exists there too. > > I haven=E2=80=99t read the mDNS relay spec in detail enough to know if it > collapses the namespace or abides by the IP subnet subdomain separate > namespaces. > > But this may be something Stuart already solved. I=E2=80=99m just not awa= re of the > solution. > > Thanks, > Tom > > > On Jul 18, 2018, at 11:34 PM, Tom Pusateri wrote: > > Speaking of name changes, you may need to handle name collision in a > special way. Since devices can=E2=80=99t see other devices names, they ca= n=E2=80=99t easily > create unique names. So if there are 10 light bulbs from the same vendor > all starting to register the instance name =E2=80=9Clight bulb=E2=80=9D, = the first will > succeed and the others get YXDOMAIN. The second one will realize the name > is taken but not know how to necessarily create a new name that is unique= . > The tenth light bulb might go through 9 iterations before generating a > unique name. The traditional name collision avoidance mechanism with mDNS > of incrementing a numerical suffix doesn=E2=80=99t work very well when yo= u don=E2=80=99t > know how many there are. > > It might be better to suggest a random suffix instead of a numerical one > or some other mechanism of generating unique names from the beginning. Bu= t > then they won=E2=80=99t look human readable so I don=E2=80=99t know if th= at is a > consideration. > > Thanks, > Tom > > > > On Jul 18, 2018, at 10:30 PM, Ted Lemon wrote: > > Depends on how the name change happens, but sure. If a device has a > name-change UI, it could use a very short update lease time, but the serv= er > might override it. I guess we could define an SRP delete message that > deletes all or part of a registration. > > On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri wrote= : > >> So if a device changes it=E2=80=99s name, the old one could be around fo= r a while >> along side the new name. >> >> That might be confusing. >> >> Tom >> >> On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: >> >> Okay, I've pushed fixes for the last couple of issues you guys brought >> up. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up = for >> debate. >> >> >> https://github.com/StuartCheshire/draft-sctl-service-registration/commit= /ce15160933b458a2da2346b6181ad89ed0ff1e11 >> >> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: >> >>> Yes, that=E2=80=99s the correct behavior. >>> >>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri wrote= : >>> >>>> Yeah, that needs to be more explicit. >>>> >>>> If you try to do a delete, does the server send REFUSED? >>>> >>>> Thanks, >>>> Tom >>>> >>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>>> >>>> You can't delete anything from a service name. Maybe we need to say >>>> that more explicitly. Right now the protocol doesn't allow a service= to >>>> delete itself; only to add itself. The assumption is that the servic= e >>>> will not know in advance that it is leaving the network, so service en= tries >>>> get garbage collected, rather than being explicitly deleted. Compare= to >>>> DHCPRELEASE in the DHCP protocol, which is pretty useless. >>>> >>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri >>>> wrote: >>>> >>>>> You might not need a new KEY record for the PTR but you may need to >>>>> follow the instance of the PTR to a KEY record to make sure you have >>>>> permission to delete the PTR record. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote: >>>>> >>>>> Tim and I were talking and we were wondering if one client could >>>>> delete the PTR record for a service instance that another client crea= ted? >>>>> Seems like it=E2=80=99s not protected and could be a denial of servic= e attack? So >>>>> you might need a KEY record the PTR record. >>>>> >>>>> Tom >>>>> >>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>> >>>>> Hm, you're right, that's never stated explicitly. >>>>> >>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> I don=E2=80=99t see anywhere in the document where the anycast updat= e method >>>>>> relies on UDP. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>>> >>>>>> Of course, you still have a very good point in that the anycast >>>>>> update method relies on UDP, so sending the key multiple times isn't >>>>>> desirable. But I also don't see a way around this. We could have= the >>>>>> server replicate the key, I guess. >>>>>> >>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>>>>> possibility of off-network spoofing is eliminated=E2=80=9D. So requ= iring TCP is >>>>>>> already handled. >>>>>>> >>>>>>> Searching for _dns-update._udp. still seems odd but that=E2= =80=99s >>>>>>> been going on for a while a presume. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned for= TCP. So >>>>>>> either you search for _dns-update._udp. and use TCP or you >>>>>>> register _tcp. >>>>>>> >>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP >>>>>>> packet size larger than 512, you probably wouldn=E2=80=99t want to = set it larger >>>>>>> than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus othe= r records. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>> If you are adding more KEY records, you will certainly exceed the >>>>>>> UDP update size of 512 bytes. The draft doesn=E2=80=99t mention tra= nsport but maybe >>>>>>> this should be restricted to TCP. >>>>>>> The draft does mention searching for the update server using _dns-u= pdate._udp.. >>>>>>> But then it won=E2=80=99t be able to use UDP for updates. >>>>>>> >>>>>>> Thanks, >>>>>>> Tom >>>>>>> >>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>>>> >>>>>>> Tim pointed out that we need to protect the Service Instance Name a= s >>>>>>> well as the Host Description with a KEY record, because FCFS naming= has to >>>>>>> protect both the service description and the host description. He= re are >>>>>>> the changes: >>>>>>> >>>>>>> >>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration/c= ompare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e1= 57df8da85874597 >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon wrote= : >>>>>>> >>>>>>>> The question of whether we update RFC6763 is basically "is there >>>>>>>> text that is in RFC6763 that is no longer correct because of this >>>>>>>> document." I think the answer is no. >>>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>>>>> registration protocol as DNS Dynamic Update, should this document= claim it >>>>>>>>> updates 6763? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>>>>> >>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I trie= d >>>>>>>>> to harmonize the document toward that=E2=80=94did I miss somethin= g? >>>>>>>>> >>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>>>>> Discovery? >>>>>>>>>> >>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote: >>>>>>>>>> >>>>>>>>>> BTW, the current version of the document on github now includes >>>>>>>>>> fixes for all the points that have been raised other than the on= es I said I >>>>>>>>>> wasn't going to fix: >>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registratio= n >>>>>>>>>> >>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgens= en < >>>>>>>>>>> toke@toke.dk> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>> >>>>>>>>>>>> Why can't it be just a Host Description? Might be useful for a >>>>>>>>>>>> device >>>>>>>>>>>> that just wants to register its name but doesn't (currently, o= r >>>>>>>>>>>> ever) >>>>>>>>>>>> advertise any services... >>>>>>>>>>>> >>>>>>>>>>>> Good question. What does the working group think? :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dnssd mailing list >>>>>>>>> dnssd@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> dnssd mailing list >>>>> dnssd@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>> >>>>> >>>>> >>>> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > --000000000000aada41057158da8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The service registration domain is its own domain, n= ot one of th link domains. Disambiguation is done in the UI. If there are t= wo services in two different domains with the same name otherwise, these wo= uld appear in the UI with the same name, annotated with the link name. SRP = names would follow the same convention.=C2=A0
=
I think this is talked about in the service dis= covery broker document.=C2=A0

On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri <pusateri@bangj.com> wrote:
And I think this is a general problem to solve for unicast up= dates, not necessarily a SRP thing.

For instance, while = the discovery proxy separates IP subnets which a unique subdomain to avoid = collision, using regular unicast update to a discovery proxy doesn=E2=80=99= t know about IP subnet subdomains and uses a shared namespace. The unicast = name collision problem exists there too.

I haven= =E2=80=99t read the mDNS relay spec in detail enough to know if it collapse= s the namespace or abides by the IP subnet subdomain separate namespaces.

But this may be something Stuart already solved. I= =E2=80=99m just not aware of the solution.

Thanks,=
Tom


On Jul 18, 2018, at 11:34 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Speaking of name changes, = you may need to handle name collision in a special way. Since devices can= =E2=80=99t see other devices names, they can=E2=80=99t easily create unique= names. So if there are 10 light bulbs from the same vendor all starting to= register the instance name =E2=80=9Clight bulb=E2=80=9D, the first will su= cceed and the others get YXDOMAIN. The second one will realize the name is = taken but not know how to necessarily create a new name that is unique. The= tenth light bulb might go through 9 iterations before generating a unique = name. The traditional name collision avoidance mechanism with mDNS of incre= menting a numerical suffix doesn=E2=80=99t work very well when you don=E2= =80=99t know how many there are.

It might be better to s= uggest a random suffix instead of a numerical one or some other mechanism o= f generating unique names from the beginning. But then they won=E2=80=99t l= ook human readable so I don=E2=80=99t know if that is a consideration.

Thanks,
Tom



On Jul 18, 2018, at 10:30 PM, Ted Lemo= n <mellon@fugue.co= m> wrote:

Depends on how the name change happens, but s= ure.=C2=A0 =C2=A0If a device has a name-change UI, it could use a very shor= t update lease time, but the server might override it.=C2=A0 =C2=A0I guess = we could define an SRP delete message that deletes all or part of a registr= ation.

On We= d, Jul 18, 2018 at 10:17 PM, Tom Pusateri <pusateri@bangj.com> wrote:
So if a device changes it=E2=80=99s name, the old one could be aroun= d for a while along side the new name.=C2=A0

That = might be confusing.=C2=A0
=

Tom

On Jul 18, 2018, at 10:06 PM, = Ted Lemon <mellon@= fugue.com> wrote:

Okay, I've pushed fixes for the last couple of issues you gu= ys brought up.=C2=A0 =C2=A0I used _dnssd-srp._tcp instead of _dns-update._u= dp, but that's up for debate.


On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon &= lt;mellon@fugue.com> wrote:
Yes, that=E2=80=99s the correct behavior.=C2=A0

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <pusateri@bangj.com> wro= te:
Yeah, that needs to be more explicit.=C2=A0

= If you try to do a delete, does the server send REFUSED?

Thanks,
Tom

On Jul 1= 8, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything from a servic= e name.=C2=A0 =C2=A0Maybe we need to say that more explicitly.=C2=A0 =C2=A0= Right now the protocol doesn't allow a service to delete itself; only t= o add itself.=C2=A0 =C2=A0The assumption is that the service will not know = in advance that it is leaving the network, so service entries get garbage c= ollected, rather than being explicitly deleted.=C2=A0 =C2=A0Compare to DHCP= RELEASE in the DHCP protocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM,= Tom Pusateri <pusateri@bangj.com> wrote:
You might not need a new KEY record for the PTR but you may need = to follow the instance of the PTR to a KEY record to make sure you have per= mission to delete the PTR record.

Tom

On Jul 18, 2018, at 7:37 PM, Tom = Pusateri <pusate= ri@bangj.com> wrote:

Tim and I were talking and we were wondering if = one client could delete the PTR record for a service instance that another = client created? Seems like it=E2=80=99s not protected and could be a denial= of service attack? So you might need a KEY record the PTR record.

Tom

On Jul 18= , 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:

Hm, you&#= 39;re right, that's never stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom = Pusateri <pusateri@bangj.com> wrote:
I don=E2=80=99t see anywhere in the document where the anycast updat= e method relies on UDP.=

Tom


On Jul 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wro= te:

Of course, you still have a = very good point in that the anycast update method relies on UDP, so sending= the key multiple times isn't desirable.=C2=A0 =C2=A0But I also don'= ;t see a way around this.=C2=A0 =C2=A0We could have the server replicate th= e key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Just saw this in Section 2: = "By requiring the use of TCP, the possibility of off-network spoofing = is eliminated=E2=80=9D. So requiring TCP is already handled.

=
Searching for=C2=A0_dns-update._udp.<domain> still seems odd but= that=E2=80=99s been going on for a while a presume.

Tom


On Jul 18, 2018, at 12:15 P= M, Tom Pusateri <pusateri@bangj.com> wrote:

Loo= king in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. So ei= ther you search for _dns-update._udp.&= lt;domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set the maximum UDP packe= t size larger than 512, you probably wouldn=E2=80=99t want to set it larger= than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other recor= ds.

=
Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com>= wrote:

If you are adding more KEY rec= ords, you will certainly exceed the UDP update size of 512 bytes. The draft= doesn=E2=80=99t mention transport but maybe this should be restricted to T= CP.
The draft does mention searching for the update server using=C2=A0<= span style=3D"white-space:pre-wrap">_dns-update._udp.<domain>. But th= en it won=E2=80=99t be able to use UDP for updates.

Thanks,
Tom

On Jul 17, 2018, at= 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Tim pointed out that we need to protect the Service= Instance Name as well as the Host Description with a KEY record, because F= CFS naming has to protect both the service description and the host descrip= tion.=C2=A0 =C2=A0Here are the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon = <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basically &= quot;is there text that is in RFC6763 that is no longer correct because of = this document."=C2=A0 I think the answer is no.

= On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com>= wrote:
Ok, just checking. So given that = 6763 semi-defines service registration protocol as DNS Dynamic Update, shou= ld this document claim it updates 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wro= te:

The title of RFC 6763 is DNS-Based Ser= vice Discovery.=C2=A0 =C2=A0So I tried to harmonize the document toward tha= t=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusate= ri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery different from DNS Service= Discovery?

Is this meant to distinguish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon &= lt;mellon@fugue.com> wrote:


On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@= fugue.com> wrote:
On Mon, Ju= l 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgensen &= lt;toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com>= ; writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

<= /blockquote>
Good question.=C2=A0 =C2=A0What does the working = group think?=C2=A0 =C2=A0:)=C2=A0


_______= ________________________________________
dnssd mailing list=
dnssd@= ietf.org
https://www.ietf.org/mailman/listinfo/dnssd=

_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd maili= ng list
dnssd@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
=

_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd


________________________________________= _______
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnss= d

=


_______________________________________________
dnssd mailing list
dnssd@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd maili= ng list
dnssd@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnssd

--000000000000aada41057158da8d-- From nobody Thu Jul 19 07:15:48 2018 Return-Path: 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 91271130FDC for ; Thu, 19 Jul 2018 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 N3LHm1PMdc2M for ; Thu, 19 Jul 2018 07:15:03 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 1F3041310CA for ; Thu, 19 Jul 2018 07:15:02 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id q10-v6so8249032wrd.4 for ; Thu, 19 Jul 2018 07:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9s2dzryjhSl0he2WmNyKGa0TM4xQiQwrcSM560xhaBg=; b=QoFZkYN8CPrU1UF8Dp79xijNmeUhN2IlHswNyzMvJMi731JYBLWgocc2ebqNnhZZ/n K33YwOntKYDcqQxce+yo2XiMf3HmqZpm38qxyakEKo8vCnJezGtAmGcJKTYB8mB4lyco qX+1jAyxZqAqBbxXmqYVrDiU5QIupRgDR0ZmVgyunQvDI9wvGSbJIhcVHopAUzpZFjB6 QonLTM5Ti4zShEbefAkYuzYi1Fnq2BokXFYY5vQ1w3xNZgwc7XGoqJej7YQb5kFo7Prb H6o2jAqaTZUBZ0cJm1mpt21xycG/CFNEQ9XsS3Fe4rxfWWkREYMEzbcbc4Cy5ycvKr3w pDFg== 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; bh=9s2dzryjhSl0he2WmNyKGa0TM4xQiQwrcSM560xhaBg=; b=Hk8rK6NSJmzyNi77st018+v8JXC77jm78j8XiUto8OG27x16D/6VNJ/uojiszLKng0 M0PRjWMN1fGo5Ri+kSysh46MNwBLD2BfohRWpqdAgUjn0/KZIV+8KocgeCiVYdyEnZPU K5XI1Ntj9s0kLBBLdB0EHDjMvsOhp6W7nRUYO7jK44AktrmGQs4+f53DuspV3Om6TRQR +gAroKnhhPv+yHiCVe5DaIlAEYmRpGE76/OB97lT4FeZPzSllpohCvSlr6/EbEz/xx1S nLODAKjq8dajZGCC764hawaS0fq+cgjuTt/NzWf2qtdlFMBospHXOlDYihD11vWoh8tf FOqw== X-Gm-Message-State: AOUpUlGZJRNGMFRcDwbd0gYn96CKZ3t6cytiIbnjNCnTofAN/kq8nWys L3Xp7RKt2aRBicV7vo6lPUwMOzdnZpg3J2jrcIUmrBu7s9M= X-Google-Smtp-Source: AAOMgpcpZ4OMh6RQ7QmMFKif4I1N14I31ASY99vMczTvi8alJsTh5yCSSlGeOajzHJoSJeXDuZR0b5GKPz0EoVWU4Ps= X-Received: by 2002:adf:9086:: with SMTP id i6-v6mr7344452wri.271.1532009700444; Thu, 19 Jul 2018 07:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 07:14:59 -0700 (PDT) In-Reply-To: References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <87d0vn7b5t.fsf@toke.dk> <87a7qq6fdk.fsf@toke.dk> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> <4C40C3A6-5871-4F44-8351-20948F5C5958@bangj.com> From: Tim Wicinski Date: Thu, 19 Jul 2018 10:14:59 -0400 Message-ID: To: dnssd Content-Type: multipart/alternative; boundary="000000000000fcce7405715acd23" Archived-At: Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:15:14 -0000 --000000000000fcce7405715acd23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've read this draft and I support its adoption. One thing to add to the document once it's adopted that any DNS naming involving _underscore names addresses the new BCP from DNSOP draft-ietf-dnsop-attrleaf Tim On Thu, Jul 19, 2018 at 7:55 AM, Ted Lemon wrote: > The service registration domain is its own domain, not one of th link > domains. Disambiguation is done in the UI. If there are two services in t= wo > different domains with the same name otherwise, these would appear in the > UI with the same name, annotated with the link name. SRP names would foll= ow > the same convention. > > I think this is talked about in the service discovery broker document. > > On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri wrote: > >> And I think this is a general problem to solve for unicast updates, not >> necessarily a SRP thing. >> >> For instance, while the discovery proxy separates IP subnets which a >> unique subdomain to avoid collision, using regular unicast update to a >> discovery proxy doesn=E2=80=99t know about IP subnet subdomains and uses= a shared >> namespace. The unicast name collision problem exists there too. >> >> I haven=E2=80=99t read the mDNS relay spec in detail enough to know if i= t >> collapses the namespace or abides by the IP subnet subdomain separate >> namespaces. >> >> But this may be something Stuart already solved. I=E2=80=99m just not aw= are of >> the solution. >> >> Thanks, >> Tom >> >> >> On Jul 18, 2018, at 11:34 PM, Tom Pusateri wrote: >> >> Speaking of name changes, you may need to handle name collision in a >> special way. Since devices can=E2=80=99t see other devices names, they c= an=E2=80=99t easily >> create unique names. So if there are 10 light bulbs from the same vendor >> all starting to register the instance name =E2=80=9Clight bulb=E2=80=9D,= the first will >> succeed and the others get YXDOMAIN. The second one will realize the nam= e >> is taken but not know how to necessarily create a new name that is uniqu= e. >> The tenth light bulb might go through 9 iterations before generating a >> unique name. The traditional name collision avoidance mechanism with mDN= S >> of incrementing a numerical suffix doesn=E2=80=99t work very well when y= ou don=E2=80=99t >> know how many there are. >> >> It might be better to suggest a random suffix instead of a numerical one >> or some other mechanism of generating unique names from the beginning. B= ut >> then they won=E2=80=99t look human readable so I don=E2=80=99t know if t= hat is a >> consideration. >> >> Thanks, >> Tom >> >> >> >> On Jul 18, 2018, at 10:30 PM, Ted Lemon wrote: >> >> Depends on how the name change happens, but sure. If a device has a >> name-change UI, it could use a very short update lease time, but the ser= ver >> might override it. I guess we could define an SRP delete message that >> deletes all or part of a registration. >> >> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri >> wrote: >> >>> So if a device changes it=E2=80=99s name, the old one could be around f= or a >>> while along side the new name. >>> >>> That might be confusing. >>> >>> Tom >>> >>> On Jul 18, 2018, at 10:06 PM, Ted Lemon wrote: >>> >>> Okay, I've pushed fixes for the last couple of issues you guys brought >>> up. I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up= for >>> debate. >>> >>> https://github.com/StuartCheshire/draft-sctl- >>> service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11 >>> >>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon wrote: >>> >>>> Yes, that=E2=80=99s the correct behavior. >>>> >>>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri >>>> wrote: >>>> >>>>> Yeah, that needs to be more explicit. >>>>> >>>>> If you try to do a delete, does the server send REFUSED? >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon wrote: >>>>> >>>>> You can't delete anything from a service name. Maybe we need to say >>>>> that more explicitly. Right now the protocol doesn't allow a servic= e to >>>>> delete itself; only to add itself. The assumption is that the servi= ce >>>>> will not know in advance that it is leaving the network, so service e= ntries >>>>> get garbage collected, rather than being explicitly deleted. Compar= e to >>>>> DHCPRELEASE in the DHCP protocol, which is pretty useless. >>>>> >>>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri >>>>> wrote: >>>>> >>>>>> You might not need a new KEY record for the PTR but you may need to >>>>>> follow the instance of the PTR to a KEY record to make sure you have >>>>>> permission to delete the PTR record. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri wrote= : >>>>>> >>>>>> Tim and I were talking and we were wondering if one client could >>>>>> delete the PTR record for a service instance that another client cre= ated? >>>>>> Seems like it=E2=80=99s not protected and could be a denial of servi= ce attack? So >>>>>> you might need a KEY record the PTR record. >>>>>> >>>>>> Tom >>>>>> >>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon wrote: >>>>>> >>>>>> Hm, you're right, that's never stated explicitly. >>>>>> >>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri >>>>>> wrote: >>>>>> >>>>>>> I don=E2=80=99t see anywhere in the document where the anycast upda= te method >>>>>>> relies on UDP. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon wrote: >>>>>>> >>>>>>> Of course, you still have a very good point in that the anycast >>>>>>> update method relies on UDP, so sending the key multiple times isn'= t >>>>>>> desirable. But I also don't see a way around this. We could hav= e the >>>>>>> server replicate the key, I guess. >>>>>>> >>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri >>>>>>> wrote: >>>>>>> >>>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the >>>>>>>> possibility of off-network spoofing is eliminated=E2=80=9D. So req= uiring TCP is >>>>>>>> already handled. >>>>>>>> >>>>>>>> Searching for _dns-update._udp. still seems odd but that= =E2=80=99s >>>>>>>> been going on for a while a presume. >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri >>>>>>>> wrote: >>>>>>>> >>>>>>>> Looking in the IANA registry, dns-update isn=E2=80=99t assigned fo= r TCP. So >>>>>>>> either you search for _dns-update._udp. and use TCP or you >>>>>>>> register _tcp. >>>>>>>> >>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP >>>>>>>> packet size larger than 512, you probably wouldn=E2=80=99t want to= set it larger >>>>>>>> than the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus oth= er records. >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri >>>>>>>> wrote: >>>>>>>> >>>>>>>> If you are adding more KEY records, you will certainly exceed the >>>>>>>> UDP update size of 512 bytes. The draft doesn=E2=80=99t mention tr= ansport but maybe >>>>>>>> this should be restricted to TCP. >>>>>>>> The draft does mention searching for the update server using >>>>>>>> _dns-update._udp.. But then it won=E2=80=99t be able to us= e UDP >>>>>>>> for updates. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tom >>>>>>>> >>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon wrote: >>>>>>>> >>>>>>>> Tim pointed out that we need to protect the Service Instance Name >>>>>>>> as well as the Host Description with a KEY record, because FCFS na= ming has >>>>>>>> to protect both the service description and the host description. = Here >>>>>>>> are the changes: >>>>>>>> >>>>>>>> https://github.com/StuartCheshire/draft-sctl- >>>>>>>> service-registration/compare/ae53618d8231733701ccdda4d33669 >>>>>>>> 2a529c9f6b...5c85181881b84ed1132d544e157df8da85874597 >>>>>>>> >>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The question of whether we update RFC6763 is basically "is there >>>>>>>>> text that is in RFC6763 that is no longer correct because of this >>>>>>>>> document." I think the answer is no. >>>>>>>>> >>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service >>>>>>>>>> registration protocol as DNS Dynamic Update, should this documen= t claim it >>>>>>>>>> updates 6763? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon wrote: >>>>>>>>>> >>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery. So I >>>>>>>>>> tried to harmonize the document toward that=E2=80=94did I miss s= omething? >>>>>>>>>> >>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service >>>>>>>>>>> Discovery? >>>>>>>>>>> >>>>>>>>>>> Is this meant to distinguish from RFC 6763? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon wrote= : >>>>>>>>>>> >>>>>>>>>>> BTW, the current version of the document on github now includes >>>>>>>>>>> fixes for all the points that have been raised other than the o= nes I said I >>>>>>>>>>> wasn't going to fix: https://github.com/ >>>>>>>>>>> StuartCheshire/draft-sctl-service-registration >>>>>>>>>>> >>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke H=C3=B8iland-J=C3=B8rgen= sen < >>>>>>>>>>>> toke@toke.dk> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ted Lemon writes: >>>>>>>>>>>>> >>>>>>>>>>>>> Why can't it be just a Host Description? Might be useful for = a >>>>>>>>>>>>> device >>>>>>>>>>>>> that just wants to register its name but doesn't (currently, >>>>>>>>>>>>> or ever) >>>>>>>>>>>>> advertise any services... >>>>>>>>>>>>> >>>>>>>>>>>>> Good question. What does the working group think? :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dnssd mailing list >>>>>>>>>>> dnssd@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dnssd mailing list >>>>>>>>>> dnssd@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dnssd mailing list >>>>>>>> dnssd@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dnssd mailing list >>>>>>> dnssd@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dnssd mailing list >>>>>> dnssd@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dnssd >>>>>> >>>>>> >>>>>> >>>>> >>> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --000000000000fcce7405715acd23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've read this draft and I support its adoption. =C2= =A0 One thing to add to the document once it's adopted that any DNS nam= ing involving _underscore names
addresses the new BCP from DNSOP draft-= ietf-dnsop-attrleaf

Tim
=C2=A0=C2=A0

On Thu, J= ul 19, 2018 at 7:55 AM, Ted Lemon <mellon@fugue.com> wrote:
The service registr= ation domain is its own domain, not one of th link domains. Disambiguation = is done in the UI. If there are two services in two different domains with = the same name otherwise, these would appear in the UI with the same name, a= nnotated with the link name. SRP names would follow the same convention.=C2= =A0

I think this i= s talked about in the service discovery broker document.=C2=A0

On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri <pusateri@bangj.com> wrote:<= br>
And I think this is a general problem to solv= e for unicast updates, not necessarily a SRP thing.

For = instance, while the discovery proxy separates IP subnets which a unique sub= domain to avoid collision, using regular unicast update to a discovery prox= y doesn=E2=80=99t know about IP subnet subdomains and uses a shared namespa= ce. The unicast name collision problem exists there too.

I haven=E2=80=99t read the mDNS relay spec in detail enough to know = if it collapses the namespace or abides by the IP subnet subdomain separate= namespaces.

But this may be something Stuart alre= ady solved. I=E2=80=99m just not aware of the solution.

Thanks,
Tom


On Jul 18, 2018, at 11:34 PM, Tom Pusateri <pusateri@bangj.com> wrote= :

Speaking of name changes, you may need to handle name collision i= n a special way. Since devices can=E2=80=99t see other devices names, they = can=E2=80=99t easily create unique names. So if there are 10 light bulbs fr= om the same vendor all starting to register the instance name =E2=80=9Cligh= t bulb=E2=80=9D, the first will succeed and the others get YXDOMAIN. The se= cond one will realize the name is taken but not know how to necessarily cre= ate a new name that is unique. The tenth light bulb might go through 9 iter= ations before generating a unique name. The traditional name collision avoi= dance mechanism with mDNS of incrementing a numerical suffix doesn=E2=80=99= t work very well when you don=E2=80=99t know how many there are.

It might be better to suggest a random suffix instead of a numeric= al one or some other mechanism of generating unique names from the beginnin= g. But then they won=E2=80=99t look human readable so I don=E2=80=99t know = if that is a consideration.

Thanks,
Tom<= /div>



On Jul= 18, 2018, at 10:30 PM, Ted Lemon <mellon@fugue.com> wrote:

Depends on how the name change happens, but sure.=C2=A0 =C2=A0If a= device has a name-change UI, it could use a very short update lease time, = but the server might override it.=C2=A0 =C2=A0I guess we could define an SR= P delete message that deletes all or part of a registration.

On Wed, Jul 18, 2018 at 10= :17 PM, Tom Pusateri <pusateri@bangj.com> wrote:
So if a device= changes it=E2=80=99s name, the old one could be around for a while along s= ide the new name.=C2=A0

That might be confusing.= =C2=A0

Tom
=

On Ju= l 18, 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:

Okay, I've pushed fixes for the las= t couple of issues you guys brought up.=C2=A0 =C2=A0I used _dnssd-srp._tcp = instead of _dns-update._udp, but that's up for debate.

htt= ps://github.com/StuartCheshire/draft-sctl-service-registration/co= mmit/ce15160933b458a2da2346b6181ad89ed0ff1e11
=

On Wed, Jul 18, 2= 018 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, that=E2=80=99s the = correct behavior.=C2=A0

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri &= lt;pusateri@bangj.c= om> wrote:
Yeah, that needs to be more explicit.=C2=A0
<= br>
If you try to do a delete, does the server send REFUSED?

Thanks,
Tom

On Jul 18, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:

You can't delete anything= from a service name.=C2=A0 =C2=A0Maybe we need to say that more explicitly= .=C2=A0 =C2=A0Right now the protocol doesn't allow a service to delete = itself; only to add itself.=C2=A0 =C2=A0The assumption is that the service = will not know in advance that it is leaving the network, so service entries= get garbage collected, rather than being explicitly deleted.=C2=A0 =C2=A0C= ompare to DHCPRELEASE in the DHCP protocol, which is pretty useless.
<= div class=3D"gmail_extra">
On Wed, Jul 18, 20= 18 at 7:40 PM, Tom Pusateri <pusateri@bangj.com> wrote:
=
You might not need a new KEY record for the PTR but= you may need to follow the instance of the PTR to a KEY record to make sur= e you have permission to delete the PTR record.

Tom
On Jul 18, 2018, at 7:37 PM, = Tom Pusateri <pu= sateri@bangj.com> wrote:

Tim and I were talking= and we were wondering if one client could delete the PTR record for a serv= ice instance that another client created? Seems like it=E2=80=99s not prote= cted and could be a denial of service attack? So you might need a KEY recor= d the PTR record.

Tom

On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:
Hm, you're right, that's nev= er stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri = <pusateri@bangj.= com> wrote:
I don=E2=80=99t see = anywhere in the document where the anycast update method relies on UDP.

Tom


On Jul 18, 201= 8, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:

Of course, you still have a very good point = in that the anycast update method relies on UDP, so sending the key multipl= e times isn't desirable.=C2=A0 =C2=A0But I also don't see a way aro= und this.=C2=A0 =C2=A0We could have the server replicate the key, I guess.<= /div>

On Wed, Jul = 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wro= te:
Just saw this in Section 2: "By requiri= ng the use of TCP, the possibility of off-network spoofing is eliminated=E2= =80=9D. So requiring TCP is already handled.

Searching f= or=C2=A0_dns-update._udp.<domain> still seems odd but that=E2=80=99s = been going on for a while a presume.

Tom


On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com&= gt; wrote:

=
Looki= ng in the IANA registry, dns-update isn=E2=80=99t assigned for TCP. So eith= er you search for _dns-update._udp.<= ;domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set the maximum UDP packet = size larger than 512, you probably wouldn=E2=80=99t want to set it larger t= han the MTU and 1480 isn=E2=80=99t big enough for 3 KEYs plus other records= .

Tom

On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com>= wrote:

If you a= re adding more KEY records, you will certainly exceed the UDP update size o= f 512 bytes. The draft doesn=E2=80=99t mention transport but maybe this sho= uld be restricted to TCP.
The draft does mention searching for the upda= te server using=C2=A0_dns-update._udp.= <domain>. But then it won=E2=80=99t be able to use UDP for updat= es.

=
Thanks,
Tom

On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:

Ti= m pointed out that we need to protect the Service Instance Name as well as = the Host Description with a KEY record, because FCFS naming has to protect = both the service description and the host description.=C2=A0 =C2=A0Here are= the changes:


On Mon, Jul 16, 2018 at 6:42 PM, Ted Le= mon <mellon@fugue.com> wrote:
The question of whether we update RFC6763 is basical= ly "is there text that is in RFC6763 that is no longer correct because= of this document."=C2=A0 I think the answer is no.

On Mon, Jul 16, 2018 at 6:4= 1 PM, Tom Pusateri <pusateri@bangj.com> wrote:
Ok, just checking. So given that 6763 semi-defines service r= egistration protocol as DNS Dynamic Update, should this document claim it u= pdates 6763?

Thanks,
Tom

On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:
The title of RFC 6763 = is DNS-Based Service Discovery.=C2=A0 =C2=A0So I tried to harmonize the doc= ument toward that=E2=80=94did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pu= sateri <pusateri@bangj.com> wrote:
How is=C2=A0DNS-Based Service Discovery diffe= rent from DNS Service Discovery?

Is this meant to distingu= ish from RFC 6763?
=C2=A0
Thanks,
Tom

On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:

BTW, the current version of th= e document on github now includes fixes for all the points that have been r= aised other than the ones I said I wasn't going to fix:=C2=A0https://github.com/StuartCheshire/draft-sctl-service-= registration

On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com> wrote:
On Mon, Jul 16, 2018 at 5:27 = PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:<= br>
Ted Lemon <mellon@fugue.com> writes:

Why can't it be just a Host Description? Might be useful for= a device
that just wants to register its name but doesn't (currently, or ever) advertise any services...

Good question.=C2=A0 =C2=A0= What does the working group think?=C2=A0 =C2=A0:)=C2=A0
<= br>

_______= ________________________________________
dnssd mailing= list
d= nssd@ietf.org
https://www.ietf.org/mailman/listinfo= /dnssd

_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_____________________________= __________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailm= an/listinfo/dnssd


_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd



___________________________________= ____________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listi= nfo/dnssd




_______________________________________________
dnssd mailing list<= br>dnssd@ietf.orghttps://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________=
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--000000000000fcce7405715acd23-- From nobody Thu Jul 19 07:23:38 2018 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBFC130E3D; Thu, 19 Jul 2018 07:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dnssd-chairs@ietf.org, dnssd@ietf.org, tim.chown@jisc.ac.uk, Tim Chown , rfc-editor@rfc-editor.org, draft-ietf-dnssd-hybrid@ietf.org, terry.manderson@icann.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153201020010.5306.9741295777016365918.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 07:23:20 -0700 Archived-At: Subject: [dnssd] Protocol Action: 'Discovery Proxy for Multicast DNS-Based Service Discovery' to Proposed Standard (draft-ietf-dnssd-hybrid-08.txt) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.27 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 14:23:20 -0000 The IESG has approved the following document: - 'Discovery Proxy for Multicast DNS-Based Service Discovery' (draft-ietf-dnssd-hybrid-08.txt) as Proposed Standard This document is the product of the Extensions for Scalable DNS Service Discovery Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ Technical Summary Classic mDNS and DNS-SD only operate across the scope of a single link. There is thus a challenge in service discovery for multi-link networks, from home networks through to large enterprises or campuses. This document specifies a type of proxy called a "Multicast Discovery Proxy" (or just "Discovery Proxy") that uses Multicast DNS to discover Multicast DNS records on its local link, and makes corresponding DNS records visible in the Unicast DNS namespace. Host queries are forwarded to proxies on remote links which perform multicast resolution of those queries, returning unicast answers. Hosts may use LLQ or DNS Push for queries, to subscribe to DNS updates to obtain timely information. Other optimisations are described in other WG documents. Working Group Summary The draft moved fairly smoothly through various iterations. Until late in the process it was referred to the Hybrid Proxy, hence the draft file name, but it was then renamed the Discovery Proxy to allow the potential for a future Advertising Proxy to be defined with a clear, distinct purpose. Document Quality The appendix describes existing implementation status, which includes at least three (part) implementations. There is interest amongst multiple vendors to take the work forward, beyond just Apple. There has been a good number of reviews performed on the document over the past year or so, and there has been close cooperation with the DNSOP WG through Tim and Suzanne on the DNS Push and DNS Session Signal drafts that the Proxy can benefit from. Personnel Tim Chown is the document shepherd (and co-chair of the WG), and Terry Manderson is the Responsible AD. From nobody Thu Jul 19 07:53:17 2018 Return-Path: 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 A19AD129385 for ; Thu, 19 Jul 2018 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 LNBpRLSc7bfD for ; Thu, 19 Jul 2018 07:53:13 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD62C127333 for ; Thu, 19 Jul 2018 07:53:13 -0700 (PDT) Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 8E840D82 for ; Thu, 19 Jul 2018 10:51:19 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> Date: Thu, 19 Jul 2018 10:53:11 -0400 To: dnssd X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:53:16 -0000 I=E2=80=99ll 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=E2=80=99s 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=E2=80=99s a profile of usage. Therefore, I don=E2=80=99t think we should call this Service = Registration Protocol which is a generic name because it isn=E2=80=99t a = generic solution.=20 I propose =E2=80=9CDNS Update Profile for Constrained Services=E2=80=9D. Without a name change, I don=E2=80=99t support adoption of this draft. Thanks, Tom From nobody Thu Jul 19 08:35:44 2018 Return-Path: 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 3B7EA130D7A for ; Thu, 19 Jul 2018 08:35:39 -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 FqBWALsg0eVT for ; Thu, 19 Jul 2018 08:35:36 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 3A79A130E3C for ; Thu, 19 Jul 2018 08:35:36 -0700 (PDT) Received: by mail-it0-x229.google.com 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; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> 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-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:35:40 -0000 --0000000000002c18ea05715bee74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99ll 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 us= ed > 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=E2=80=99s 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=E2=80=99s a profile of usage. > > Therefore, I don=E2=80=99t think we should call this Service Registration= Protocol > which is a generic name because it isn=E2=80=99t a generic solution. > > I propose =E2=80=9CDNS Update Profile for Constrained Services=E2=80=9D. > > Without a name change, I don=E2=80=99t support adoption of this draft. > > Thanks, > Tom > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000002c18ea05715bee74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tom, there are a couple of problems with what you've s= aid.=C2=A0 =C2=A0First, the goal of SRP is actually to provide a general so= lution for registering services to be discovered using DNSSD.=C2=A0 =C2=A0I= t is not for constrained devices only, although that is certainly one case = where it's valuable.=C2=A0 =C2=A0So we can't call it a registration= protocol only for constrained devices.

Secondly, this i= s DNS Update.=C2=A0 =C2=A0It's just that DNS Update without something l= ike this doesn't work=C2=A0as a registration protocol, and we= 9;ve seen that because DNS-SD over DNS hasn't taken the world by storm = in the years since it's been published.=C2=A0 =C2=A0This 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.=C2=A0 =C2=A0This speci= fication acknowledges that and talks about how to address the problem.=C2= =A0 =C2=A0We've also had discussions about this at the mic.=C2=A0 =C2= =A0This protocol is however the enabling technology required to solve those= problems as well.=C2=A0 =C2=A0Those will be subsets of this, rather than t= his being a subset of those.

So although I underst= and where you are coming from, I do not agree with your analysis of the sit= uation.

On Thu, Jul 19, 2018 at 10:53 AM, Tom Pusateri <pusateri@bangj.com&= gt; wrote:
I=E2=80=99ll put this o= n 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 regist= ration in a single Update message for constrained devices but there is no e= ncryption or authentication/authorization mechanism that can be used outsid= e an administrative domain.

Since RFC 6763 summarizes in Appendix A:
=C2=A0 =C2=A0 =C2=A0 Service discovery requires a service registration prot= ocol.
=C2=A0 =C2=A0 =C2=A0 DNS already has one: DNS Dynamic Update

DNS Dynamic Update is generic and can handle service registration from anyw= here under any conditions. But it=E2=80=99s chatty and so there is a need f= or something that is more efficient for constrained devices.

draft-sctl-service-registration does this by instructing you how to us= e DNS Dynamic Update is a particular way. It=E2=80=99s a profile of usage.<= br>
Therefore, I don=E2=80=99t think we should call this Service Registration P= rotocol which is a generic name because it isn=E2=80=99t a generic solution= .

I propose =E2=80=9CDNS Update Profile for Constrained Services=E2=80=9D.
Without a name change, I don=E2=80=99t support adoption of this draft.

Thanks,
Tom

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--0000000000002c18ea05715bee74-- From nobody Thu Jul 19 08:38:18 2018 Return-Path: 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 89EBF130EAB for ; Thu, 19 Jul 2018 08:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 39slTNTtAgev for ; Thu, 19 Jul 2018 08:38:12 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BE812F1A6 for ; Thu, 19 Jul 2018 08:38:12 -0700 (PDT) Received: from [2001:67c:1232:144:d42:eb7c:2d4a:e5b3] (port=51763) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgB0I-0001J6-BF for dnssd@ietf.org; Thu, 19 Jul 2018 16:38:10 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_F06739AA-C612-49F0-A6EA-83825BB4A8F8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <95A894F9-0F5B-42CE-9358-604B4C851CDC@sinodun.com> References: <7C2520E6-C1F6-49B2-900D-38E1F624B2E7@sinodun.com> To: dnssd@ietf.org Date: Thu, 19 Jul 2018 11:38:03 -0400 X-Mailer: Apple Mail (2.3445.9.1) X-BlackCat-Spam-Score: 14 Archived-At: Subject: [dnssd] Privacy Enhancements and Assessment Proposed RG (PEARG) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:38:17 -0000 --Apple-Mail=_F06739AA-C612-49F0-A6EA-83825BB4A8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As mentioned at the mic: - details of PEARG are here: https://trac.ietf.org/trac/irtf/wiki/pearg = - RFC6973 =E2=80=9CPrivacy Considerations for Internet Protocols=E2=80=9D = https://datatracker.ietf.org/doc/html/rfc6973 = Sara > Begin forwarded message: >=20 > From: Sara Dickinson > Subject: Welcome to the Privacy Enhancements and Assessment Proposed = RG mailing list! > Date: 5 July 2018 at 12:51:17 GMT-4 > To: pearg@irtf.org >=20 > Dear All,=20 >=20 > We would like to announce the first meeting (a side meeting) of the = Privacy Enhancements and Assessment (PEA) Proposed RG to be held at IETF = 102 in Montreal. We are waiting confirmation of our time slot, we have = requested 18:40 on Tuesday 17th July and will post to this list as soon = as we have more details. >=20 > The chairs for this Proposed RG are: > Sara Dickinson (sara@sinodun.com ) and=20 > Shivan Sahib (ssahib@salesforce.com ) >=20 > This side meeting is planned as an informal discussion for parties = interested in participating in the Proposed RG. There will be an = overview of the proposed charter (see below) and we would like to = solicit feedback on the charter and also possible future work in the = group.=20 >=20 > As food for thought we believe that there are several ongoing = privacy-relevant efforts and discussions in various IETF and IRTF groups = that would benefit from a dedicated group for analysis, including: >=20 > - [QUIC] Privacy leaks via passive network management via the proposed = QUIC spin bit. > - [QUIC] Connection migration and multipath privacy properties of = exposed packet header information. > - [DoH] Privacy implications for various use cases and for server = operators. > - [DRUI (BoF)] Privacy implications of DNS resolver discovery = mechanisms. > - [DNSSD] Private service discovery threat model formulation and = solution analysis. > - [DPRIVE] BCP for operators of DNS privacy services. Padding profile = analysis. > - [ICNRG] Privacy implications of unencrypted content requests = (interests). > - [TRANS] Privacy implications of certificate transparency gossiping. > - [RTCWEB] Privacy issues around exposing private IP addresses in = WebRTC >=20 > Equally important, there is active research being conducted in the = academic and open source communities around privacy preserving = techniques that the IETF and IRTF could benefit from adopting. >=20 > We=E2=80=99ll also discuss scheduling future meetings, including = possible co-location with events other than the IETF.=20 >=20 > Best regards >=20 > Sara & Shivan >=20 >=20 >=20 >=20 > # Draft Charter >=20 > ## Background >=20 > Privacy is an increasingly desirable and often necessary property for = Internet technologies. Evidence suggests that attacks on societal, = community, and individual privacy occur with non-negligible frequency, = as discussed in detail in RFC 7258 and in protocol-specific documents = such as RFC 7626. Pervasive monitoring [RFC 7258], is a well known = attack on privacy at incredible scale. The IETF and IAB responses to = such attacks is to push for widespread end-to-end encryption. = Understanding attacks on privacy and the costs of addressing them is = critical for ensuring the longevity, usability, and viability of = Internet technologies.=20 >=20 > Alongside such work the emergence of global and region-specific = legislation in this area e.g. GDPR provides further motivation for = enhancing available privacy techniques (beyond end-to-end encryption), = advancing the state-of-the-art for privacy in protocols, and for = assessing privacy of existing protocols.=20 >=20 > ## Objectives >=20 > The Privacy Enhancements and Assessments Research Group (PEARG) is a = general forum for discussing and reviewing privacy enhancing = technologies for network protocols and distributed systems in general, = and for the IETF in particular. The PEARG serves as a bridge between = theory and practice, bringing new privacy-enhancing technologies to the = Internet community and promoting an understanding of the use and = applicability of these mechanisms via Informational RFCs (in the = tradition of HMAC [RFC 2104]). Our goal is to provide a forum for = discussion and analyzing the cryptographic and practical aspects of = privacy protocols, and to offer guidance on the use of emerging = techniques and new uses of existing ones. IETF working groups = developing protocols that include privacy technology elements are = welcome to bring questions concerning the protocols to the PEARG for = advice. >=20 > The Assessments objective of PEARG will include partaking in the = following tasks: >=20 > 1) Reviewing privacy properties (informed by but not limited to the = analysis in RFC6973) of existing and emerging IETF protocols, >=20 > 2) Developing specifications in the tradition of RFC 6973 that offer = guidance for protocol design and development and advice on = privacy-enhancement. =20 >=20 > This work will involve outreach to ensure close cooperation with = similar and related efforts in IETF.=20 >=20 > ## Meetings >=20 > The PEARG will meet two to three times per year, as deemed necessary = by the chairs and according to demand. At least one PEARG meeting will = be co-located with an IETF meeting per year. The PEARG will also meet = collocated with relevant academic conferences, such as the Privacy = Enhancing Technologies Symposium (PETS), yearly if possible. = Participation is open to all.=20 >=20 > Meetings are by default open with open attendance and published = proceedings, with remote participation and recording as provided by the = meeting venue, according to the IRTF=E2=80=99s IPR policy.=20 >=20 > The chairs may at times appoint at their pleasure =E2=80=9Cclosed=E2=80=9D= design teams with lesser reporting requirements (though results will be = open). This will allow for some limited discussions in which = participants require extra privacy. This does not relax the Note Well: = for all activities of the RG, as for all other activities of IRTF, the = Note Well applies [https://www.ietf.org/about/note-well/ = ]. >=20 > ## Collaborations >=20 > PEARG will actively engage with academic and open source (e.g. Tor = project, EFF, OTF) communities and encourage specification of key = privacy-enhancing technologies in Informational or Experimental RFCs. = Example current emerging technologies where interest is solicited = include: >=20 > 1. Differential privacy techniques applied to networked and = distributed systems > 2. Anti-fingerprinting techniques > 3. Potential uses of MPC for privacy=20 >=20 > PEARG is related to security and cryptographic protocols in the IETF = and IRTF. Among the IETF working groups, PEARG will collaborate to = ensure and encourage collaboration so that desirable privacy properties = are upheld for the Internet community. PEARG will also collaborate with = the CFRG to ensure cryptographic techniques and algorithms are used = appropriately for their intended purpose. >=20 >=20 --Apple-Mail=_F06739AA-C612-49F0-A6EA-83825BB4A8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
As mentioned at the mic:

- details of PEARG are here: https://trac.ietf.org/trac/irtf/wiki/pearg
- RFC6973 =E2=80=9CPrivacy Considerations for Internet = Protocols=E2=80=9D https://datatracker.ietf.org/doc/html/rfc6973

Sara


Begin forwarded message:

From: = Sara Dickinson <sara@sinodun.com>
Subject: = Welcome to the = Privacy Enhancements and Assessment Proposed RG mailing list!
Date: = 5 July 2018 at 12:51:17 = GMT-4
To: = pearg@irtf.org

Dear All, 

We would like to announce the first = meeting (a side meeting) of the Privacy Enhancements and Assessment = (PEA) Proposed RG to be held at IETF 102 in Montreal. We are waiting = confirmation of our time slot, we have requested 18:40 on Tuesday 17th = July and will post to this list as soon as we have more = details.

The = chairs for this Proposed RG are:
Sara Dickinson (sara@sinodun.com) = and 
Shivan Sahib (ssahib@salesforce.com)

This side meeting is planned as an = informal discussion for parties interested in participating in the = Proposed RG. There will be an overview of the proposed charter (see = below) and we would like to solicit feedback on the charter and also = possible future work in the group. 

As food for thought we believe that = there are several ongoing privacy-relevant efforts and discussions in = various IETF and IRTF groups that would benefit from a dedicated group = for analysis, including:

- [QUIC] Privacy leaks via = passive network management via the proposed QUIC spin bit.
-= [QUIC] Connection migration and multipath privacy properties of exposed = packet header information.
- [DoH] Privacy implications = for various use cases and for server operators.
- [DRUI = (BoF)] Privacy implications of DNS resolver discovery mechanisms.
- [DNSSD] Private service discovery threat model formulation = and solution analysis.
- [DPRIVE] BCP for operators of DNS = privacy services. Padding profile analysis.
- [ICNRG] = Privacy implications of unencrypted content requests (interests).
- [TRANS] Privacy implications of certificate transparency = gossiping.
- [RTCWEB] Privacy issues around exposing = private IP addresses in WebRTC

Equally important, there is active research being conducted = in the academic and open source communities around privacy preserving = techniques that the IETF and IRTF could benefit from adopting.

We=E2=80=99= ll also discuss scheduling future meetings, including possible = co-location with events other than the IETF. 

Best regards

Sara & Shivan




# Draft Charter

## = Background

Privacy is an increasingly = desirable and often necessary property for Internet technologies. = Evidence suggests that attacks on societal, community, = and individual privacy occur with non-negligible frequency, as = discussed in detail in RFC 7258 and in protocol-specific documents such = as RFC 7626. Pervasive monitoring [RFC 7258], is a well known = attack on privacy at incredible scale.  The IETF and IAB responses = to such attacks is to push for widespread end-to-end encryption. = Understanding attacks on privacy and the costs of addressing them is = critical for ensuring the longevity, usability, and viability of = Internet technologies. 

Alongside such = work the emergence of global and region-specific legislation in this = area e.g. GDPR provides further motivation for enhancing = available privacy techniques (beyond end-to-end encryption), = advancing the state-of-the-art for privacy in protocols, and for = assessing privacy of existing protocols. 

## Objectives

The Privacy = Enhancements and Assessments Research Group (PEARG) is a general forum = for discussing and reviewing privacy enhancing technologies for = network protocols and distributed systems in general, and for the IETF = in particular. The PEARG serves as a bridge between theory and = practice, bringing new privacy-enhancing technologies to the = Internet community and promoting an understanding of the use and = applicability of these mechanisms via Informational RFCs (in the = tradition of HMAC [RFC 2104]).  Our goal is to provide a forum for = discussion and analyzing the cryptographic and practical aspects of = privacy protocols, and to offer guidance on the use of emerging = techniques and new uses of existing ones.  IETF working groups = developing protocols that include privacy technology elements are = welcome to bring questions concerning the protocols to the PEARG for = advice.

The Assessments objective of PEARG = will include partaking in the following tasks:

1) Reviewing privacy properties (informed by but not limited = to the analysis in RFC6973) of existing and emerging IETF protocols,

2) Developing specifications in the tradition = of RFC 6973 that offer guidance for protocol design and development = and advice on privacy-enhancement.  

This work will involve outreach to = ensure close cooperation with similar and related efforts in = IETF. 

## = Meetings

The PEARG = will meet two to three times per year, as deemed necessary by the chairs = and according to demand. At least one PEARG meeting will be co-located = with an IETF meeting per year. The PEARG will also meet collocated with = relevant academic conferences, such as the Privacy = Enhancing Technologies Symposium (PETS), yearly if possible. = Participation is open to all. 

Meetings = are by default open with open attendance and published proceedings, with = remote participation and recording as provided by the meeting = venue, according to the IRTF=E2=80=99s IPR policy. 

The chairs may at times appoint at their = pleasure =E2=80=9Cclosed=E2=80=9D design teams with lesser reporting = requirements (though results will be open).  This will allow = for some limited discussions in which participants require extra = privacy.  This does not relax the Note Well:  for all = activities of the RG, as for all other activities of IRTF, the Note = Well applies [https://www.ietf.org/about/note-well/].

## Collaborations

PEARG will actively engage with = academic and open source (e.g. Tor project, EFF, OTF) communities and = encourage specification of key privacy-enhancing technologies in = Informational or Experimental RFCs.  Example current emerging = technologies where interest is solicited include:

1. Differential privacy techniques applied to networked and = distributed systems
2. Anti-fingerprinting techniques
3. Potential uses of MPC for privacy 

PEARG is related to security and cryptographic protocols in = the IETF and IRTF. Among the IETF working groups, PEARG will collaborate = to ensure and encourage collaboration so that desirable privacy = properties are upheld for the Internet community. PEARG will also = collaborate with the CFRG to ensure cryptographic techniques and = algorithms are used appropriately for their intended purpose.



= --Apple-Mail=_F06739AA-C612-49F0-A6EA-83825BB4A8F8-- From nobody Thu Jul 19 09:24:19 2018 Return-Path: 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 D484B130E63 for ; Thu, 19 Jul 2018 09:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: 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 qlRuk86fu30q for ; Thu, 19 Jul 2018 09:24:15 -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 6A1D7130DCB for ; Thu, 19 Jul 2018 09:24:15 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1532017447; bh=/QMRgL5iTfZMBeGCfGu60rAuvq+Z5T9eCNugh10bPIE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gr565eerqu/JSIsjcLckhIoZ3NX/QABbkdyNDQogQnaTALHizqDDzrQzlkzBOzhmw JljVoNdLc39W9D8FHmoCXSv7LB3VFU4ChdKalW3nMGshJhRI+BxFT5rnnM+yC0LZTo VfLedbT1tHcNj/Wf1pr14Sy+ZB2rWFbNRdG5lj86Lk4+MXnQptXY2ywHpQICi72Nq4 uxat1eFCSZ+LdURCYQaEDxg0ZCIVSafY0wo421piYMRgBgF3UE//2mUBo7XLxsho/O EId81LyH62pUmptm0LlB7cOLNKi/2BsRz+lgVLK9blFWWH/WoPSeIHR+bW6iH4klGX bvZfw2r0Lkm6w== To: Ted Lemon , Tom Pusateri Cc: dnssd In-Reply-To: References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> Date: Thu, 19 Jul 2018 18:23:53 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3e719eu.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:24:18 -0000 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 From nobody Thu Jul 19 10:33:14 2018 Return-Path: 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 AD377130EA8 for ; Thu, 19 Jul 2018 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 qGvk2ddBCTiZ for ; Thu, 19 Jul 2018 10:33:10 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700092.outbound.protection.outlook.com [40.107.70.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366BD130DC6 for ; Thu, 19 Jul 2018 10:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PO7/3QK4f0giGcB5CyxqPBSwZ0qXi4CjrR+fR/97sDk=; b=i+sAi+ecnU3YhOq68o6HCfP5lHoteMPJBQwuJuPbWcgsVs0O+v8TOsympNDmxSy+b+uc6MDMU9SBMmnWPtXraeT7ZGpoO5xf4VDUKWV6IPwEoskm/1m1o4kgmXigPtuTni4XGjrh9ofuo+Ytw8QlPxnhCYs10eKsgaTPItDTVcM= Received: from DM5PR2101MB0805.namprd21.prod.outlook.com (10.167.105.149) by DM5PR2101MB0904.namprd21.prod.outlook.com (52.132.132.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.1; Thu, 19 Jul 2018 17:33:08 +0000 Received: from DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::8416:6f:8f6b:3fb7]) by DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::8416:6f:8f6b:3fb7%3]) with mapi id 15.20.0995.008; Thu, 19 Jul 2018 17:33:08 +0000 From: Dave Thaler To: "dnssd@ietf.org" Thread-Topic: draft-ietf-core-rd-dns-sd Thread-Index: AdQfewKKK/exM9gCTkyoCrbpzWy7oA== Date: Thu, 19 Jul 2018 17:33:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-19T17:33:04.1843393Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:67c:1232:144:7d00:f41:b1a7:c69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0904; 6:3BP8GWI4qV3GIQnG0S4mgjzc2vjvJGcQu2uUZY26Jj1yAToEhCVLxEMTMAo3nDevtNYNm/nu6K1ggtdOQVHEOaGV/S6LbOt1hNymiEs3L2xMrtQoQ/hGXKyEOjU7Ytn7KANbZQNcJn+LRfvgTVPZVMOZ7lFjoDH42+f7hgdpkJdRyzOWkX95vCfBJxSzQ+mFFOZHS1JmGVZEHyqb+hxVSwoMPr1I+TmFqTvyuJYH3h5MN/bU7VhSuuqMZG1JrZvPQKaGGFHoFBxhWKlxwsjlRktEnsZh0qDioMNN8FoZFaQAwA6XCe+Y4WMjplaetbRwngDJ0pc6gCKMwHNP+f+yQR56z2dFuZIegO3eCMgc1NC7OtRwKWzqq2DFzBm8o3gHDBy5wFOL8+7gRBQxINJ6PZplT+j+gRPnZQSZH2Ld2gW6TyZDdy4alMlwnmnlgobRYBuw3TlU2ggoh7/dZwjRlQ==; 5:dz9U3w6Bm6aMAgW20XH8BsZGk+WWSNH0ja2VeT5b2IJS1xDDSgzU5659YhGXkZpwWnx84BznrKky8R1uQ7C5rK51Tz2JTfrffQsG6pllMVISDjye8I7rDsJogpqi9JvfLKkNnt4sNyoczplnu1LZetEGNMveUW6FigN9FZ49CFM=; 7:G4WkInHMjEEQGABf+j82oWjdCAao3tgCsPFbKRsluP2FhoWI/6KXTufm4bli4rb6ThKNfXgYZ9cN/lYYQ46l5yc0aj6YEKNb0jsqS3QdPbwuP8XhXI6RoF8/Js2KXGBy3LtxGgxDVsrBGS/aQEhJPMJPicMxt/ECw+BhoNW77odwbHKyR5XvB85+P7+rwhMDFI//n8lGjASeTyuOpWxSDBoREsNNIQMjc2XO6DhhPzTLBGgLUyiUrcMqFxzvMj74 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bbbe5060-de8d-4ea1-6f42-08d5ed9db17f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR2101MB0904; x-ms-traffictypediagnostic: DM5PR2101MB0904: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0904; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0904; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(136003)(396003)(199004)(189003)(81166006)(1730700003)(478600001)(86362001)(8676002)(14454004)(81156014)(10290500003)(86612001)(6916009)(68736007)(53936002)(22452003)(25786009)(8936002)(5640700003)(55016002)(316002)(9686003)(6436002)(7696005)(6306002)(54896002)(6116002)(790700001)(74316002)(5660300001)(105586002)(106356001)(5250100002)(99286004)(6506007)(486006)(476003)(33656002)(8990500004)(10090500001)(7736002)(2501003)(2906002)(5630700001)(97736004)(46003)(256004)(2900100001)(14444005)(186003)(2351001)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0904; H:DM5PR2101MB0805.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6ftH/QpIuCUlS74IEhcmboyRl6+kBVMAcp1a0GTxwx526xRfB0YpGGWAxbhgPMJRmaxdv4aDyr4z7Di2hV4dtQNHNSk+vLnbCuulRQLj+S8rSsuUeE2zrHs5gou0l6l6f5cK2BVa1c5W2zKZ2rtWQo7eCskRDyLAg76Hz+wNNqDVZ/tIR8d/cM8EwXb1pHvbZ3FAyekJ1RIeBVJhobX60pSlPQvK/P/X13Yi3AW5zeHwEsdJrpChSXewkfU/WVv9TV7MLVMzB2elhg5z1u2c6D0X9HNWFyK9TFnXN66mXSVL4wGi+oBlhiDIyURD6dSheDlIH/zScm9xqUSTa0ayEr/eJZxBzYJunz3KbmkShMo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0805E5BAC69CF585A30758AAA3520DM5PR2101MB0805_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbbe5060-de8d-4ea1-6f42-08d5ed9db17f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 17:33:08.5579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0904 Archived-At: Subject: [dnssd] draft-ietf-core-rd-dns-sd 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:33:13 -0000 --_000_DM5PR2101MB0805E5BAC69CF585A30758AAA3520DM5PR2101MB0805_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the problem with mapping rt values to information in DNS-SD recor= ds... Example from doc: > An example of this more specific is "light._sub._oic._udp". Would this work: 1) Service type name ("_oic" above): change "exp" to have the value to = copy it from, instead of exp simply being Boolean 2) Make the subtype ("light" above): make this be some hash of the full= rt value. This works for URIs as well as arbitrary length rt values, at t= he expense of a tiny risk of collision. 3) Put the actual rt value into a TXT record just like the if value (wh= ich can also be a URI btw) already is. In the rare case of collision, and= app could use this to do further filtering. ? Dave --_000_DM5PR2101MB0805E5BAC69CF585A30758AAA3520DM5PR2101MB0805_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the problem with mapping rt values to info= rmation in DNS-SD records…

Example from doc:

> An example of this more specific <ServiceType> is = "light._sub._oic._udp".

 

Would this work:

1)     Service type name (“_oic” above): chang= e “exp” to have the value to copy it from, instead of exp simpl= y being Boolean

2)     Make the subtype (“light” above): make = this be some hash of the full rt value.  This works for URIs as well a= s arbitrary length rt values, at the expense of a tiny risk of collision.

3)     Put the actual rt value into a TXT record just like= the if value (which can also be a URI btw) already is.   In the = rare case of collision, and app could use this to do further filtering.

?

 

Dave

 

--_000_DM5PR2101MB0805E5BAC69CF585A30758AAA3520DM5PR2101MB0805_-- From nobody Thu Jul 19 11:27:50 2018 Return-Path: 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 8F54713113D for ; Thu, 19 Jul 2018 11:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PvtM02dyVFJO for ; Thu, 19 Jul 2018 11:27:40 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFABD131137 for ; Thu, 19 Jul 2018 11:27:39 -0700 (PDT) Received: from dhcp-9458.meeting.ietf.org (dhcp-9458.meeting.ietf.org [31.133.148.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id D1030E03; Thu, 19 Jul 2018 14:25:44 -0400 (EDT) From: Tom Pusateri Message-Id: <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B10DD905-A94D-401D-B771-E05A11E13BD4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 14:27:37 -0400 In-Reply-To: <87y3e719eu.fsf@toke.dk> Cc: Ted Lemon , dnssd To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 18:27:48 -0000 --Apple-Mail=_B10DD905-A94D-401D-B771-E05A11E13BD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 19, 2018, at 12:23 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Ted Lemon > writes: >=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> So although I understand where you are coming from, I do not agree >> with your analysis of the situation. >=20 > 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. >=20 > Oh, and I do also support adoption of the draft, if that hasn't been > clear from my previous messages :) >=20 > -Toke While you want it to be used for this purpose, it=E2=80=99s not really = designed for crossing administrative boundaries. 1. You need encryption which it can=E2=80=99t 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=E2=80=99t a problem for you. 3. You don=E2=80=99t 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 --Apple-Mail=_B10DD905-A94D-401D-B771-E05A11E13BD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 19, 2018, at 12:23 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <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=E2=80=99s not really = designed for crossing administrative boundaries.

1. You need encryption which it can=E2=80=99t 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=E2=80=99t a problem for you.
3. You = don=E2=80=99t 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



= --Apple-Mail=_B10DD905-A94D-401D-B771-E05A11E13BD4-- From nobody Thu Jul 19 11:35:35 2018 Return-Path: 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 CB058130E7F for ; Thu, 19 Jul 2018 11:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: 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 wXcf4uImFfEq for ; Thu, 19 Jul 2018 11:35:31 -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 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; d=toke.dk; 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: <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> Date: Thu, 19 Jul 2018 20:35:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87va9b3wgp.fsf@toke.dk> 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-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." 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=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Ted Lemon > writes: >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> So although I understand where you are coming from, I do not agree >>> with your analysis of the situation. >>=20 >> 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. >>=20 >> Oh, and I do also support adoption of the draft, if that hasn't been >> clear from my previous messages :) >>=20 >> -Toke > > While you want it to be used for this purpose, it=E2=80=99s not really > designed for crossing administrative boundaries. > > 1. You need encryption which it can=E2=80=99t 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=E2=80=99t 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 devices. > 3. You don=E2=80=99t 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. -Toke From nobody Thu Jul 19 12:10:00 2018 Return-Path: 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 ; 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 ; 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 ; Thu, 19 Jul 2018 12:09:50 -0700 (PDT) Received: by mail-it0-x22e.google.com 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; 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> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> 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-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:09:58 -0000 --00000000000056a2ff05715eecb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B8iland-J=C3=B8rgensen 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=E2=80=99s not really de= signed > for crossing administrative boundaries. > > 1. You need encryption which it can=E2=80=99t 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=E2= =80=99t a > problem for you. > 3. You don=E2=80=99t 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 > > > > --00000000000056a2ff05715eecb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You actually talked in your presentation on the charter ab= out an SRP relay.=C2=A0 =C2=A0I think that is a good approach for Toke'= s use case.=C2=A0 =C2=A0I don't think there is any way to do service re= gistration across administrative boundaries without some kind of trust mech= anism of this sort.

On Thu, Jul 19, 2018 at 2:27 PM, Tom Pusateri <= ;pusateri@bangj.com= > wrote:

<= div>
On Jul 19, 2018, at 12:23 PM, Toke H= =C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:

Ted Lemon <mellon@fugue.com> writes:

Tom, there ar= e 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 b= e discovered using DNSSD. It is not for constrained
devices only, althou= gh that is certainly one case where it's valuable.
So we can't c= all it a registration protocol only for constrained
devices.

Seco= ndly, this is DNS Update. It's just that DNS Update without
somethin= g 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 i= n the years since it's been published. This specification is
intende= d 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= 9;t work for all use cases. This specification
acknowledges that and tal= ks about how to address the problem. We've
also had discussions abou= t this at the mic. This protocol is however
the enabling technology requ= ired to solve those problems as well.
Those will be subsets of this, rat= her than this being a subset of
those.

So although I understand w= here you are coming from, I do not agree
with your analysis of the situa= tion.

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
<= span style=3D"font-family:Menlo-Regular;font-size:13px;font-style:normal;fo= nt-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:= start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0= px;text-decoration:none;float:none;display:inline!important">no means just = a thing for constrained devices.

O= h, and I do also support adoption of the draft, if that hasn't been
clear from my previous messages :)

-Toke

Wh= ile you want it to be used for this purpose, it=E2=80=99s not really design= ed for crossing administrative boundaries.

1. You = need encryption which it can=E2=80=99t do because of the multiple packets r= equired to do key management.
2. DNS Update does solve the admini= strative boundary problem at the expense of more packets back and forth to = the update server. That isn=E2=80=99t a problem for you.
3. You d= on=E2=80=99t need the features this draft is good at.
4. This dra= ft could do more than constrained devices but then DNS Update already does = it.

Tom



=
--00000000000056a2ff05715eecb1-- From nobody Thu Jul 19 12:18:21 2018 Return-Path: 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 069D7130E8B for ; Thu, 19 Jul 2018 12:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: 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 ZUddYWfgLy8u for ; Thu, 19 Jul 2018 12:18:16 -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 74A5C130DC6 for ; Thu, 19 Jul 2018 12:18:16 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1532027894; bh=SiFPprHdhAMhFvTb/pKw059uXhxFROqrQNeyMpeLLKI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OenRk7/g3jlareIndSeYzlgh5Dn62h18D2gCoqGy6Cl3mePadFWsZmILPiskan/5O kKg8QovjsIQUzWGKWPNCMOq2sOqj16sd/uBPdLtN7m/lY5TtHjSYfGSwK5JMUxiWdu YNnJILvfCoXp2oTIwrac3XONc+Ti05FNSogJg4x/NpU2dssH5iPZ28Aw2xKS3bKaLB JzFOK6a/iGMmbZAX6F4IQPWTpUzPnFnibROXndvBKIoz1oOEKhO/coGtagXRruCBFb sq+ieHmFZdRSkQAOvO6aA8NBIUudtHKyTOqlag5dZIy9WVdGIcAR5sL3/TBwW8lHkk rPMpcJSI7qgYA== To: Ted Lemon , Tom Pusateri Cc: dnssd In-Reply-To: References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> Date: Thu, 19 Jul 2018 21:18:06 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pnzj3uhd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:18:20 -0000 Ted Lemon writes: > 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 disagree. I don't want to run a relay. > I don't think there is any way to do service registration across > administrative boundaries without some kind of trust mechanism of this > sort. Sure there is: source address validation. Say I run a dyndns service at dyndns.example.org. I provide an admin interface where someone can register and pick a subdomain, say myhome.dyndns.example.org, and register their IPv6 prefix. I then configure my registration server to accept updates from that v6 prefix for subdomains of myhome.dyndns.example.org on a TOFU basis. All the user then has to do is add regserver.dynsdns.example.org as their _dns-update._tcp.myhome.dynsdns.example.org SRV record on their home network, and presto, all their devices can now register themselves in global DNS. -Toke From nobody Thu Jul 19 12:19:20 2018 Return-Path: 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 7A4A6130E8B for ; Thu, 19 Jul 2018 12:19:18 -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 Aq3nuLjOMNYw for ; Thu, 19 Jul 2018 12:19:16 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 F399C130DBE for ; Thu, 19 Jul 2018 12:19:15 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id r15-v6so1780488ioa.3 for ; Thu, 19 Jul 2018 12:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5VTBiCH+TnOn+M/1rIrI+epRHZnJlQo1geELr8OK1Bw=; b=p2LpijnaxjcLlHyDQ7khCVqMUHiq7WrQA2vcDAN9KWiq+bzrGX3E3422ngRlobto/0 rbNZjOrAa4UwUxpDYdMt213UyUrElpIbDyX5tc9DEVgFqaotXquCrhE8xmbhSonaB9Gy OvK1HqYecMsntuH2dTLBRN5356e7cF2nKq6PhMQYUDuTcDzca6JQQS+iI8tpCKBSN1Eu 7g+J9FGHAOU9o14lEYKVb/Tx7f6QZURbRFLRur4tn3AxyfNMUX835JIwCVzVkKIs5NHp LFVwVEaqnYjHlIRS3nJLakVdmyepj4j2LaNlGAZEXYBMdAReZtvGFG30sTizuoAT/T2k 14NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5VTBiCH+TnOn+M/1rIrI+epRHZnJlQo1geELr8OK1Bw=; b=F9ub3nezwRgBsAzBEamqoSBI2J+X5R5RQc8csRL8tGbRXd8ci1Gg1LXW41UYzQICZ+ aweovLS9Pv2C97c4X/RDSjVggoRFx7oNlNvrwegh9anhjZT9ZlcJLxXfpxk6D8x3IYV8 WhRym5EOJ/80nhNwjOJHiHezzBH1RkWhTknv4/RflK5YVMcQp4U9K5U2ChPI8qcZPP4C DaAdrBqfvFeBu7gx5s9Cd0kGYgjD7LZM16Dzx1A2VbumRI66rJCn6f1/CL2TsW6SsGof iVyzFqIiduFB4uqw51A81jFI6NG7x5WXP5bUHCWg9h5CHlmRqcvPXnd+zbVFIb1Hp1u0 LBOA== X-Gm-Message-State: AOUpUlEpmdUnZP2ZlBG2pNtaCWp0xFi41UTamTMnY9CCUOA20jazHco0 a3+/7YWENtkh9qylkPhP6DLglsETGTT73GtsAGgSxf65Swo= X-Google-Smtp-Source: AAOMgpcDERopFj8FVCVTx0qvIofUmVeVQoCloSU837bnt0RjBg2DhQ1l4uvhGTn149mMAroE0u3thjGv2b642oQfGkY= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr10132690ioe.32.1532027955254; Thu, 19 Jul 2018 12:19:15 -0700 (PDT) MIME-Version: 1.0 References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> <87pnzj3uhd.fsf@toke.dk> In-Reply-To: <87pnzj3uhd.fsf@toke.dk> From: Ted Lemon Date: Thu, 19 Jul 2018 15:19:04 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Tom Pusateri , dnssd Content-Type: multipart/alternative; boundary="0000000000000f284905715f0e76" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:19:19 -0000 --0000000000000f284905715f0e76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, but there are privacy implications to that approach. On Thu, Jul 19, 2018 at 3:18 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > 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 disagree. I don't want to run a relay. > > > I don't think there is any way to do service registration across > > administrative boundaries without some kind of trust mechanism of this > > sort. > > Sure there is: source address validation. > > Say I run a dyndns service at dyndns.example.org. I provide an admin > interface where someone can register and pick a subdomain, say > myhome.dyndns.example.org, and register their IPv6 prefix. I then > configure my registration server to accept updates from that v6 prefix > for subdomains of myhome.dyndns.example.org on a TOFU basis. All the > user then has to do is add regserver.dynsdns.example.org as their > _dns-update._tcp.myhome.dynsdns.example.org SRV record on their home > network, and presto, all their devices can now register themselves in > global DNS. > > -Toke > --0000000000000f284905715f0e76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, but there are privacy implications to that app= roach.=C2=A0

On Thu, Jul 19, 2018 at 3:18 PM Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

> 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 disagree. I don't want to run a relay.

> I don't think there is any way to do service registration across > administrative boundaries without some kind of trust mechanism of this=
> sort.

Sure there is: source address validation.

Say I run a dyndns service at dyndns.example.org. I provide an admin interface where someone can register and pick a subdomain, say
myhome.dyndns.example.org, and register their IPv6 prefix. I the= n
configure my registration server to accept updates from that v6 prefix
for subdomains of myhome.dyndns.example.org on a TOFU basis. All= the
user then has to do is add regserver.dynsdns.example.org as = their
_dns-update._tcp.myhome.dynsdns.example.org SRV record on t= heir home
network, and presto, all their devices can now register themselves in
global DNS.

-Toke
--0000000000000f284905715f0e76-- From nobody Thu Jul 19 12:21:37 2018 Return-Path: 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 928EA130EC5 for ; Thu, 19 Jul 2018 12:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: 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 Ompv20ki12UL for ; Thu, 19 Jul 2018 12:21:32 -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 25960130EB2 for ; Thu, 19 Jul 2018 12:21:32 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1532028090; bh=S1OEXCslfSbtEzIVdtsSrh6o4bL1t722k5WAc/vtows=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mo6TAbvDzyKirvlFNvj+CNfh/4pXjpOmcHrp6j3w+VnZ8Q2KjUKQb/1RcFXPmfQ04 ipzr74AXJ1g/fzk8crEYLz0b23dtZXbgWwybU6m1mEV435d9WiD3jl6SlYCu+zwoyd XYBfrGddEA/o0g9fLxpJmhsOGcay8XQsUqVLlPJUh18tUv3xF/KbHLLhk4IYFlZmlo VNkxSeu9k8gSJk+Q7LXuq8tQ9pSdSHVJ45JQpdDaSwdolyUGtnpuYp1lGKExGsqLsN 3vevUNwONId82g0xOHXtNmUC6FQLNx7qo6brC3UoYQrE1xEuG/eEVOn8VIi1zT3yfG vxRwP9eeRyJnw== To: Ted Lemon Cc: Tom Pusateri , dnssd In-Reply-To: References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> <87pnzj3uhd.fsf@toke.dk> Date: Thu, 19 Jul 2018 21:21:25 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in5b3ubu.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:21:34 -0000 Ted Lemon writes: > Sure, but there are privacy implications to that approach. Yeah, I'm assuming that things going into global DNS are public by default... -Toke From nobody Thu Jul 19 12:48:38 2018 Return-Path: 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 077D4130E8B for ; Thu, 19 Jul 2018 12:48:36 -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 ooV73pfqDZoV for ; Thu, 19 Jul 2018 12:48:34 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D602C130DC6 for ; Thu, 19 Jul 2018 12:48:33 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id i18-v6so8058662ioj.13 for ; Thu, 19 Jul 2018 12:48:33 -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=JTvIqGvoiaZ/ovDWNTTiS+CR6DBTG/+2pDUAs2LIQyw=; b=nzzpSAa8kUOG45Bedt68nvNQVMuPV5xKAk0JyqnjPJ619Z8h8S4kTSITaMg1nO9z1B e3pVNEo6+e3vIN7gKiGWy23LP+QZtqRnd5xr7nKpCsEeMuVXn/jz1qjgcQhCXSUoZzA5 bblm/hg3xZUxiVkoYh/ZSDI+gEWDqWdqW9wwE5zoaUwNbhebkcWHpryn7CeHbFLMQvqb 0PWyNlORM9jIJlr2E7VW9FEyRnL9wbaPxJUtu39PZ1z2VGVfq2hTAyfaNpxRuAH23fhW +IPxNEYURy7mGayXR7BhF7GwCnsM0S5rPmDOGwLs9VkChnPovrqYSiTH+vjiSm5mJDNm H10A== 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=JTvIqGvoiaZ/ovDWNTTiS+CR6DBTG/+2pDUAs2LIQyw=; b=Qy+GWVgifnD99VJKs5MF4UEmhCwO4RS9klthGBSQv7GL48QTdKDbJubJEaVcHi1NuE BHdZ5VVaheLfGs05jr/ow++hRGeYIBk3AUcw3Q8Xgp1D8P6GU/kL8b0wrjeDkWIHu5v6 iZbUchqkjcg9PiR8YwZrkvQ89ghtzqd2TAl2ntAnRAKu9lHTctt/bnFM1ISyaG1tR3b1 TvBy8sOrKVtGACvzBl3CLHUmVDtzmosJVL9p8gXRhLJqh71LNvx/44e+Raj4571RqD3X 49iki1OgqnpwS2Jwl4PrtUwl4jv60s17TKaaEcarCef6hYGPjEA4hNMhExwW0cftEAZS Exkw== X-Gm-Message-State: AOUpUlFYvoSj7QenAYgJtSo64sNTSbzP79QxckJz4R3zKjXhXubI4ZNu lGLlvNqcq3Qq9dTARJiZMp9EpKmO+TlyDzCx+Xrm8A== X-Google-Smtp-Source: AAOMgpebMHNeRQ3v6YYX4p6qlFM8pQe+yurtbgBoR/p0x43wDCbVAkrvQ/gM4DIprg7i6UViXOhWEgMxAvTNIJ2Z1gw= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr10224200ioe.85.1532029713145; Thu, 19 Jul 2018 12:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 12:47:52 -0700 (PDT) In-Reply-To: <87in5b3ubu.fsf@toke.dk> References: <9CEB602B-87CA-4F5A-A0B9-C514528AB9AD@bangj.com> <87y3e719eu.fsf@toke.dk> <8FF70F87-733C-4DBB-9AAC-85BEA1067105@bangj.com> <87pnzj3uhd.fsf@toke.dk> <87in5b3ubu.fsf@toke.dk> From: Ted Lemon Date: Thu, 19 Jul 2018 15:47:52 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Tom Pusateri , dnssd Content-Type: multipart/alternative; boundary="000000000000d672d505715f762f" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:48:36 -0000 --000000000000d672d505715f762f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed. But I don't think we can assume that the DNS SRP stuff goes into is always public. On Thu, Jul 19, 2018 at 3:21 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > Sure, but there are privacy implications to that approach. > > Yeah, I'm assuming that things going into global DNS are public by > default... > > -Toke > --000000000000d672d505715f762f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed.=C2=A0 =C2=A0But I don't think we can assume th= at the DNS SRP stuff goes into is always public.

On Thu, Jul 19, 2018 at 3:21 PM, Toke = H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

> Sure, but there are privacy implications to that approach.

Yeah, I'm assuming that things going into global DNS are public = by
default...

-Toke

--000000000000d672d505715f762f-- From nobody Thu Jul 19 13:46:37 2018 Return-Path: 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 C315D130F16 for ; Thu, 19 Jul 2018 13:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 XzzvIQIrNZHI for ; Thu, 19 Jul 2018 13:46:32 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B930130F55 for ; Thu, 19 Jul 2018 13:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532033190; x=2395946790; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wmUutD5io3mEYOWnk3uYrI/rAZHKccUcnduwa3Jye1Q=; b=mCOD92P+VBnpAUe21AvKx4NnoablStZR0l1nHS4B9qO1Pa0au049fZp5/xFeLhxV PgYYkni/TOwe0/2CriXh5p+9jCLJU2OPKAmcenVzz1Hzrk5TtdjoA3tqSFO2k84k gNXZFPSDINa4d5FVk6fYTVMNq7wb0J8cMAuZ16n3uUo7/Z9tksrdkF/eYeGno5Ul PwTECV3Nlj5+iUQPUcbIH5cG4k/s3U92lmHXmGgp6GGQG6Hc8xC1N04NBRcSQH5f rys57dgLiCfrUk2J3O4Jek3YA+7TR+atd6kYypLFpnWSCnxWUAYyJ60r26bVmMKB l95AWHXaPgoR/s5CFBOQ1g==; X-AuditID: 11ab0217-d27ff70000003e90-81-5b50f8a65871 Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id B8.0B.16016.6A8F05B5; Thu, 19 Jul 2018 13:46:30 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_X49EkeOLjqJRrxD8u7osow)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC400CQ2SDGOKA0@ma1-mtap-s02.corp.apple.com> for dnssd@ietf.org; Thu, 19 Jul 2018 13:46:30 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC400I00RWWMI00@nwk-mmpp-sz09.apple.com> for dnssd@ietf.org; Thu, 19 Jul 2018 13:46:29 -0700 (PDT) X-Va-A: X-Va-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-Va-E-CD: 9c855f368aea6c440814cc19677fec2a X-Va-R-CD: 56c5bb3281c3a20d48efbae67335c2ad X-Va-CD: 0 X-Va-ID: e4c3b30e-7029-4efb-a89a-986a639229c6 X-V-A: X-V-T-CD: 30a9c062f6936833101a7e3ef1ad5808 X-V-E-CD: 9c855f368aea6c440814cc19677fec2a X-V-R-CD: 56c5bb3281c3a20d48efbae67335c2ad X-V-CD: 0 X-V-ID: d28cafd9-fda0-4c99-bfc1-b0c65bec4ba2 Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC400H00RVHU200@nwk-mmpp-sz09.apple.com> for dnssd@ietf.org; Thu, 19 Jul 2018 13:46:29 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-19_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.235.59.137] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC400D85SDDSAA0@nwk-mmpp-sz09.apple.com> for dnssd@ietf.org; Thu, 19 Jul 2018 13:46:29 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <959AFDB8-3663-4BA0-9603-B59F9D72301A@apple.com> Date: Thu, 19 Jul 2018 16:46:24 -0400 To: dnssd X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUiqOHDprvsR0C0wZ7fUhbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvb1t5gLnvJUnO06xNjAuIO7i5GDQ0LARGLXU/4uRi4OIYH9 TBIHzzSwdDFycvAKCEr8mHwPzGYWCJO482gOG0TRYSaJK4sWsIIkhATmMklcXOcIYksIsEv8 +bWDBcLWlph0cR8zjL10VRtcvHX7L3YIm0tiwdbTrBC2rsTGr/OYIGw2ifUnlkDZWhL7Tt1i gbF7pmxihrG7n6xjhLA5Jc5/mQg1U0fi2vqzLBCHzmGSeHMLZlC2xNuFv9kg7GCJP4d6mCEe 6GCSaHugBGILC0hLdF24ywoKFTagBQfWGIGYwkAzp6+KgISJjcSEO6fBprAIqEosnXUPbLqI gJTErt9zoDYpSvSvOcQ2gVF2FlIwzkIKRghbS+L7o1agOAeQLS9x8LwsRFhT4tm9T+xIwgsY 2VYxCucmZuboZuYZGeslFhTkpOol5+duYgRF/mom8R2Mn18bHmIU4GBU4uGNuBsQLcSaWFZc mXuIUZqDRUmc98MusWghgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCLfFooEWB60l1prP5d1 wu+/SX/jlFPn/Des+PHr7qoFs2Z312kGvkq8aG4hvE8i9PbWt31lUot1K2ZbJpr/1DHn3/1Q Z4Zp/pJfAW7rVW5NKTcSZpjsGPTLxydmtZQuS0jwya076p7tc1t5IjRh6dXbq1YdeVJ1p23P iv2Nxuuu5yqJi792O6DEUpyRaKjFXFScCAA9x19I3QIAAA== Archived-At: Subject: [dnssd] Minutes for DNSSD IETF 102 Uploaded 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:46:35 -0000 --Boundary_(ID_X49EkeOLjqJRrxD8u7osow) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi all, The minutes for DNSSD IETF 102 have been uploaded: https://datatracker.ietf.org/doc/minutes-102-dnssd/ Thanks to Barbara Stark for taking minutes and to Tim Wattenberg for being Jabber scribe! Please review the minutes and check that anything you said today is correctly represented. If anything is incorrect, please let me know by email ASAP. Thanks, David --Boundary_(ID_X49EkeOLjqJRrxD8u7osow) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi all,

The minutes for DNSSD IETF 102 have been uploaded:

Thanks to Barbara Stark for taking minutes and to Tim Wattenberg for being Jabber scribe!

Please review the minutes and check that anything you said today is correctly represented.
If anything is incorrect, please let me know by email ASAP.

Thanks,
David
--Boundary_(ID_X49EkeOLjqJRrxD8u7osow)-- From nobody Fri Jul 20 09:44:55 2018 Return-Path: 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 49D88130F3E for ; Fri, 20 Jul 2018 09:44:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OWgAcnZhB_RQ for ; Fri, 20 Jul 2018 09:44:50 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 9B361130E54 for ; Fri, 20 Jul 2018 09:44:50 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id a5-v6so10822962qtp.2 for ; Fri, 20 Jul 2018 09:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=R6KD+Azv8GO7yPGP0Zd6DJ0C9nXSbVtHvlNVWEh7DYI=; b=ECrIp7qci4qTw40rtqDCF9kU88g79qQ7Lo36IzMJGfWwaDWmsMelFNxEi3KNHIu811 BWn+DfyZ59sKr/ozlNnFlmNw5Ur6VDUCyxVWL695YP7B4hdN3dwCCyDO5eB9tVQIfEEc 62c2GZcpUCUxuFldQXpGiTgk/tjYO+BFY1aDyPlxFnakO1gm6g3FxEe1BYjV30nQCDng LlrbRqM1soJOyUiuPAtJRWSXiYpKdiVXhZdqkkoc/tGmFIs36aMlHrGVqNHFAZ/X9jBi 4yXkxQj/hsaF9p9ifUeDrTqgi267l0BOE3axKq0VD/wx44dFIEvsRO27hJAYR3rYv43u gLfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=R6KD+Azv8GO7yPGP0Zd6DJ0C9nXSbVtHvlNVWEh7DYI=; b=V18Tbk/lkNDYS2bFU8w5QPoZwDA8Gu78sNidU6KELEIfWdU+5OWWM1cVBhAosTeHYG gAIDJ0VycPGVIEnxX31O5mXXzlOhi/6+tBa8h2zEEq4+ZqGU5dtlogtqRKyftZAPpCvB x8az+UALdHS63TSilsZDulVVMdwI4fBr7pd3vqSGg54Zw6J1nXgUop2W6LazdCgMaQo1 ntpyiQbfzK3eKrd2PDOaqz+ZZFaqOdNYG5LL6mWrUOyVCxHM0YPwo/7xZrhJy7XOq1Qq J4FBby7G1DqGtKg5B56Iaq6zLDT8+w6qDAw72XBN7vTA9i+j8P7rMr+LRJFbyi6jBK0K TUNg== X-Gm-Message-State: AOUpUlEzxLcpjh9cYvue/csQU8zUgNtFj4KrRFhO7ELqvv5ELGGxNR12 ElRZn3buyf8IFWoQeZb6/ajSPeYu X-Google-Smtp-Source: AAOMgpdmMLv14IA/ZMhZty7OXj4gg+XaFOmr+nJrCAMsrrsSlgloYl3l/OhEzJTPChisHYnYFCn7aw== X-Received: by 2002:ac8:242b:: with SMTP id c40-v6mr2634840qtc.209.1532105089244; Fri, 20 Jul 2018 09:44:49 -0700 (PDT) Received: from [10.30.20.14] (pool-96-241-84-161.washdc.fios.verizon.net. [96.241.84.161]) by smtp.gmail.com with ESMTPSA id 14-v6sm991142qty.57.2018.07.20.09.44.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 09:44:48 -0700 (PDT) From: "R. Atkinson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Fri, 20 Jul 2018 12:44:47 -0400 To: dnssd@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 16:44:53 -0000 I=E2=80=99d like to talk a little bit about use cases relating to both = mDNS & DNS-SD. This is mostly prompted by the rechartering slides (which I read online, although I have not been in Montreal for IETF this week). These are partly baked thoughts, written in haste, so are incomplete and probably have typing/editing errors in places. 1. ZeroConf / No Infrastructure Case In my experience as a user and as a consultant, is that most = (non-IETF :-) residences and most small-businesses fundamentally want a zero=20 configuration network. The outer limit of what they might view as=20 acceptable infrastructure is enabling a DHCP server (facing to the = interior)=20 on a (small) site border router that uplinks to some ISP.=20 These sites have viewed the =E2=80=9Cmagic=E2=80=9D appearance of = =E2=80=9Cit just works=E2=80=9D=20 mDNS + DNS-SD as a huge win =E2=80=94 a win that they really do not = want to lose. The main application benefit I see is printer discovery, = but=20 there are other services that do get advertised and also get used via the existing widely deployed mDNS + DNS-SD combination. (Again, their preference is for a Zero Configuration network, even if that means a less secure interior network deployment.) =20 In this environments, the site border router typically just learns = its IP address and other configuration (e.g. ISP=E2=80=99s DNS resolvers) by running = a DHCP/DHCPv6 client on the exterior router interface and trusting the ISP=E2=80=99s = DHCP reply. The same router runs a DHCP/DHCPv6 server on the interior interface, and the router=E2=80=99s DHCP replies carry along DNS resolver = information learned from the DHCP client on its exterior interface. The site does not = itself have a DNS server or even its own DNS resolver. In these environments, I rarely see any servers within a small = business. They might have a web site and email, but those often are outsourced to someone other than their ISP. Email very often is really = web-based email. If they happen to have their own domain name (example.com), they usually are NOT running the DNS name server for that and they are NOT using that domain name on internal machines. Instead, their domain = name is advertised by their (outsourced) web site hosting company, which = often also is providing them with web-based email. =20 Medical offices (in my neighborhood) seem to be migrating to = =E2=80=9Celectronic records=E2=80=9D. In practice, this often means some deal with a = local hospital. The servers are run at the hospital IT department and client-server = type software is installed on the medical office computers (or a web = application is used instead), but the servers are all offsite and run by someone = else. Privacy laws/regulations on medical data are growing, even outside = the EU, and a common belief is that it is better to outsource the = implementation so that some other organization is responsible for privacy & security compliance (e.g. HIPAA). These sites LOVE the existing mDNS + DNS-SD solution. Their only = real wish is that if they have 2 or 3 subnets, they could somehow have a = single operational mDNS environment (instead of having one mDNS environment per subnet). At least some of my clients have enabled a = non-standard mDNS proxy that is available from a well-known IP router vendor. At = their scale, they are happy with that router vendor=E2=80=99s approach. I worry = a bit that in a larger network environment too much bandwidth would be consumed=20 (as happened historically with SLP) by that vendor=E2=80=99s = implementation approach. As I have mentioned to Stuart at least once in the past, these folks = really want something that looks/feels/behaves like the old = AppleTalk/EtherTalk system =E2=80=94 although most clients don=E2=80=99t use that = terminology (because they were not working age when those capabilities were widely deployed by = sites with Apple products). 2. Larger Enterprise / Campus / Building-sized Case Larger businesses usually do have their own internal mail servers, = file servers, and DNS servers. Often their authoritative DNS servers are different/separate from their DNS resolvers. These often have 2 = logically different WiFi networks, one for employees/internal-users and one = for guests. Sometimes the =E2=80=9Cguest=E2=80=9D wireless is outside a = corporate firewall and only sees the public Internet. Other times the =E2=80=9Cguest=E2= =80=9D network is in a kind of DMZ environment, so that guest=E2=80=99s can discover = printers and send out print jobs, but does NOT have unconstrained access to the organization=E2=80=99s internal network. In this environment, often there is more concern about = =E2=80=9Csecurity=E2=80=9D, which=20 seems to mean some combination of =E2=80=9Caccess control=E2=80=9D = (about what a=20 given node can see) and =E2=80=9Cauthentication=E2=80=9D (for DNS = updates) relative to=20 DNS service advertisements. (In the extreme, I have a client who = turns on every possible security feature, including use of things like = 802.1x. This results in a more secure, if somewhat more brittle, = deployment.) In this environment and for these users, there is MUCH more = willingness to have IT staff configure =E2=80=9Cinfrastructure=E2=80=9D (e.g., = routers, switches, servers, proxies) than in Case 1 at top of this email. This customer type also is = MUCH more interested in using access controls and/or cryptographic = authentication for any service advertisements and for any kind of DNS update. =20 However, in my experience, these customers do NOT want to configure=20= the end-user devices =E2=80=94 at least not beyond whatever DHCP (or = DHCPv6 + IPv6 ND) can provide by way of automatic configuration. Note that users in this category often want to see services for = their (logical) organization, regardless of where they are within the = campus (or which campus for multi-campus organizations). Someone who = works in =E2=80=9Cengineering=E2=80=9D wants to see all of the = =E2=80=9Cengineering=E2=80=9D groups services plus whatever printers are geographically near the person=E2=80=99s = current location. In old AppleTalk this flexibility was pretty easily = deployed and=20 also pretty easily used. Postulate: My postulate, again based on my own non-scientific sample, is that = there are at least 2 distinct use cases for DNS-SD (and mDNS). One case = is small scale, so scalability of solution is not as important. The = other case requires scalability. The small sites are not usually very security = conscious, while the larger sites usually are very security conscious. So it is conceivable that some potential products of this WG might = apply to one use case, but not to the other use case. I think we need to = all keep both use cases in mind as the WG ponders current/future work in this = WG. Yours, Ran =20= From nobody Fri Jul 20 11:04:04 2018 Return-Path: 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 7290E130E16 for ; Fri, 20 Jul 2018 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ym6JCRiYTNQt for ; Fri, 20 Jul 2018 11:03:59 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBE7130DE7 for ; Fri, 20 Jul 2018 11:03:58 -0700 (PDT) Received: from [31.133.159.116] (dhcp-9f74.meeting.ietf.org [31.133.159.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3667B9A; Fri, 20 Jul 2018 14:02:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16A5327f) In-Reply-To: Date: Fri, 20 Jul 2018 14:03:57 -0400 Cc: dnssd@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "R. Atkinson" Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:04:03 -0000 Thanks Ran.=20 I think this is important input for the reCharter.=20 Tom > On Jul 20, 2018, at 12:44 PM, R. Atkinson wrote: >=20 >=20 > I=E2=80=99d like to talk a little bit about use cases relating to both mDN= S & DNS-SD. >=20 > This is mostly prompted by the rechartering slides (which I read online, > although I have not been in Montreal for IETF this week). >=20 > These are partly baked thoughts, written in haste, so are incomplete > and probably have typing/editing errors in places. >=20 > 1. ZeroConf / No Infrastructure Case >=20 > In my experience as a user and as a consultant, is that most (non-IETF := -) > residences and most small-businesses fundamentally want a zero=20 > configuration network. The outer limit of what they might view as=20 > acceptable infrastructure is enabling a DHCP server (facing to the inter= ior)=20 > on a (small) site border router that uplinks to some ISP.=20 >=20 > These sites have viewed the =E2=80=9Cmagic=E2=80=9D appearance of =E2=80= =9Cit just works=E2=80=9D=20 > mDNS + DNS-SD as a huge win =E2=80=94 a win that they really do not want= > to lose. The main application benefit I see is printer discovery, but=20= > there are other services that do get advertised and also get used > via the existing widely deployed mDNS + DNS-SD combination. > (Again, their preference is for a Zero Configuration network, even if > that means a less secure interior network deployment.) >=20 > In this environments, the site border router typically just learns its I= P address > and other configuration (e.g. ISP=E2=80=99s DNS resolvers) by running a D= HCP/DHCPv6 > client on the exterior router interface and trusting the ISP=E2=80=99s D= HCP reply. > The same router runs a DHCP/DHCPv6 server on the interior interface, > and the router=E2=80=99s DHCP replies carry along DNS resolver informati= on learned > from the DHCP client on its exterior interface. The site does not itsel= f > have a DNS server or even its own DNS resolver. >=20 > In these environments, I rarely see any servers within a small business.= > They might have a web site and email, but those often are outsourced > to someone other than their ISP. Email very often is really web-based e= mail. > If they happen to have their own domain name (example.com), they > usually are NOT running the DNS name server for that and they are NOT > using that domain name on internal machines. Instead, their domain name= > is advertised by their (outsourced) web site hosting company, which ofte= n > also is providing them with web-based email. >=20 > Medical offices (in my neighborhood) seem to be migrating to =E2=80=9Cel= ectronic > records=E2=80=9D. In practice, this often means some deal with a local h= ospital. > The servers are run at the hospital IT department and client-server type= > software is installed on the medical office computers (or a web applicat= ion > is used instead), but the servers are all offsite and run by someone els= e. > Privacy laws/regulations on medical data are growing, even outside the E= U, > and a common belief is that it is better to outsource the implementation= > so that some other organization is responsible for privacy & security > compliance (e.g. HIPAA). >=20 > These sites LOVE the existing mDNS + DNS-SD solution. Their only real > wish is that if they have 2 or 3 subnets, they could somehow have a sin= gle > operational mDNS environment (instead of having one mDNS environment > per subnet). At least some of my clients have enabled a non-standard m= DNS > proxy that is available from a well-known IP router vendor. At their s= cale, > they are happy with that router vendor=E2=80=99s approach. I worry a b= it that in a > larger network environment too much bandwidth would be consumed=20 > (as happened historically with SLP) by that vendor=E2=80=99s implementa= tion approach. >=20 > As I have mentioned to Stuart at least once in the past, these folks re= ally > want something that looks/feels/behaves like the old AppleTalk/EtherTal= k > system =E2=80=94 although most clients don=E2=80=99t use that terminolo= gy (because they > were not working age when those capabilities were widely deployed by si= tes > with Apple products). >=20 >=20 > 2. Larger Enterprise / Campus / Building-sized Case >=20 > Larger businesses usually do have their own internal mail servers, file= > servers, and DNS servers. Often their authoritative DNS servers are > different/separate from their DNS resolvers. These often have 2 logica= lly > different WiFi networks, one for employees/internal-users and one for > guests. Sometimes the =E2=80=9Cguest=E2=80=9D wireless is outside a co= rporate firewall > and only sees the public Internet. Other times the =E2=80=9Cguest=E2=80= =9D network is in > a kind of DMZ environment, so that guest=E2=80=99s can discover printer= s and > send out print jobs, but does NOT have unconstrained access to the > organization=E2=80=99s internal network. >=20 > In this environment, often there is more concern about =E2=80=9Csecurit= y=E2=80=9D, which=20 > seems to mean some combination of =E2=80=9Caccess control=E2=80=9D (abo= ut what a=20 > given node can see) and =E2=80=9Cauthentication=E2=80=9D (for DNS updat= es) relative to=20 > DNS service advertisements. (In the extreme, I have a client who turns= > on every possible security feature, including use of things like 802.1x= . > This results in a more secure, if somewhat more brittle, deployment.) >=20 > In this environment and for these users, there is MUCH more willingness= > to have IT staff configure =E2=80=9Cinfrastructure=E2=80=9D (e.g., rout= ers, switches, servers, proxies) > than in Case 1 at top of this email. This customer type also is MUCH m= ore > interested in using access controls and/or cryptographic authentication= for > any service advertisements and for any kind of DNS update. =20 >=20 > However, in my experience, these customers do NOT want to configure=20 > the end-user devices =E2=80=94 at least not beyond whatever DHCP (or DH= CPv6 > + IPv6 ND) can provide by way of automatic configuration. >=20 > Note that users in this category often want to see services for their > (logical) organization, regardless of where they are within the campus= > (or which campus for multi-campus organizations). Someone who works > in =E2=80=9Cengineering=E2=80=9D wants to see all of the =E2=80=9Cengi= neering=E2=80=9D groups services > plus whatever printers are geographically near the person=E2=80=99s cu= rrent > location. In old AppleTalk this flexibility was pretty easily deploye= d and=20 > also pretty easily used. >=20 >=20 > Postulate: >=20 > My postulate, again based on my own non-scientific sample, is that ther= e > are at least 2 distinct use cases for DNS-SD (and mDNS). One case is > small scale, so scalability of solution is not as important. The other= case > requires scalability. The small sites are not usually very security co= nscious, > while the larger sites usually are very security conscious. >=20 > So it is conceivable that some potential products of this WG might appl= y > to one use case, but not to the other use case. I think we need to all= keep > both use cases in mind as the WG ponders current/future work in this WG= . >=20 > Yours, >=20 > Ran >=20 >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Jul 20 16:07:56 2018 Return-Path: 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 32ADA130E21 for ; Fri, 20 Jul 2018 16:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AefEdHsJHq6b for ; Fri, 20 Jul 2018 16:07:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918F7127148 for ; Fri, 20 Jul 2018 16:07:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4647F20008; Fri, 20 Jul 2018 19:23:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0F7691B39; Fri, 20 Jul 2018 19:07:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D3652C; Fri, 20 Jul 2018 19:07:51 -0400 (EDT) From: Michael Richardson To: "R. Atkinson" cc: dnssd@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 23:07:55 -0000 --=-=-= Content-Type: text/plain R. Atkinson wrote: > In these environments, I rarely see any servers within a small > business. So, no (surveillance) cameras, scanners and no shared folders? It's just printers, which are passive until you need them. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1JrRICLcPvd0N1lAQLPrAf+PQPy4A9tUIqoRd+oVRWGjzyBW/h3qVHT ad7h80v5/leF2QWyWf8rMf2PgFtLy1kMe0Hb1affIAatA4NieMv42QIALPD2GqaD AHleeNueGzCPaLv5h6RJIf0zStRhGdGAWLCdlzCAqKCS2Im7bU+51h17tru8xGEn O0rEVw8+1ecJ0YOe1rqsY8EzPlXMQm+sQUG7G2f4IsrMxpShmhYRWUvCjMkf40hR RBl1GWlKvP6zM7AVrY+juFwLkdhB3gqkG01xsXbUSli1zUG8rP5GIufcp2ib2XZk dMFA4iDK87CW2eSt9xiThk0qXQEq4n1e8eYADSqScaYuH9tv9oFr/A== =V7Z3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 21 11:40:38 2018 Return-Path: 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 DBECC130E26 for ; Sat, 21 Jul 2018 11:40:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X6AqvnfmhpMB for ; Sat, 21 Jul 2018 11:40:34 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 E4129130E15 for ; Sat, 21 Jul 2018 11:40:33 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c15-v6so13129399qtp.0 for ; Sat, 21 Jul 2018 11:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ac3bvdqCF6aE0QPadWPoB3Xhs9r0GFwKmEVYg2v/QX4=; b=Mx+YrkutadjzhzRvbnx4F5d90y+B951WaxplThLPbVCANOH8tlvqn60Q4/zozk3lus GRE/KxzUhAk0/+qLS64RVRYGN5jQDJE2C1QYwql+h4JSey2/BZLh/i3Ai3CMaLE/ajWC 2DLGcQcTgfhi4q9LLaRKw8arQ0IVHePVXYtyVTXntooa/+xE0GZ1nkdAwqrzYl6Nwo8Y DgHKnafL8HjjUM4NvcO3MKRFzUX7OrzXs3Qd7S8PfaM21m0+N6TeGRaW0QcyvaXXIoZ+ jlo1+dYUTNIiRmlxJgx7R2FoJs+rCC8Mmw998lKngsWHZuaOueOU9846WK7QtuOod3D1 nS6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ac3bvdqCF6aE0QPadWPoB3Xhs9r0GFwKmEVYg2v/QX4=; b=kxjmvW1Gw+3owJXO0FDgagyY6v9sF6XhmX+B82sCzzJsY3TG2cqshyDuLedtIdd5PD Rnh/r3iXzSvadO8e3fnYv4Tsxd77EIZyOfPmwP9yuo4wWgM4lUdOAIGD8ydD5hOOoTSa +zRF5/2VRgXTmycVSx2N8h95zLl7N2xo6ejva2Alm6wBIdUEunmOHlf5nDf1scIVoONC AtsisLOqC2Recd4CHsd9gOwpZ+UTLYAKWSvjBEWuK/MoFDKpIRakV0pOERHMvSbgrQu0 cRQAuw84sR6vUd4K860eB0ip2n+ft1TKPKROySRBpgI/N5MlqQMYnWov0sIcG8zhlvdy bt5w== X-Gm-Message-State: AOUpUlG/wqX+tZIh4RAbobNhKSKnB/CWGYqA7DdfWU5LuJyNppKfFCL7 iK4UqH7MkqU0QgRNUepvCMlYs+Yr6P8= X-Google-Smtp-Source: AAOMgpd6FJg+AY/YKv0QJLmLFCAijkzegdd23vemysikBWFS15rM+gTTtHCVL8SzLDW6AkH3R5IYPQ== X-Received: by 2002:ac8:fb1:: with SMTP id b46-v6mr6365886qtk.31.1532198433161; Sat, 21 Jul 2018 11:40:33 -0700 (PDT) Received: from [10.30.20.8] (pool-108-18-149-37.washdc.fios.verizon.net. [108.18.149.37]) by smtp.gmail.com with ESMTPSA id g19-v6sm3516250qtk.80.2018.07.21.11.40.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jul 2018 11:40:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "R. Atkinson" In-Reply-To: <7001.1532128071@localhost> Date: Sat, 21 Jul 2018 14:40:30 -0400 Cc: dnssd@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <013858C6-CFB6-481B-811C-066EBCEE3853@gmail.com> References: <7001.1532128071@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 18:40:36 -0000 > On Jul 20, 2018, at 19:07, Michael Richardson = wrote: >=20 >=20 > R. Atkinson wrote: >> In these environments, I rarely see any servers within a small >> business. >=20 > So, no (surveillance) cameras, scanners and no shared folders? > It's just printers, which are passive until you need them. With respect to small businesses,=20 =E2=80=94 I sometimes see scanners. Sometimes this is an all-in-one = printer with integrated fax and scanner. =E2=80=94 Often, particularly if there is no (brand-name omitted here) = servers, then there are no shared folders, just USB sticks and email to move = files. =E2=80=94 Printers predominate. With respect to residential, =E2=80=94 There are a wider range of mDNS devices, such as streaming = media players, OTA TV DVRs that can stream media, (surveillance) cameras,=20= and what not. =E2=80=94 Scanners might appear also, of course, as might fax machines. Ran From nobody Mon Jul 23 05:48:12 2018 Return-Path: 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 26D6D130E76 for ; Mon, 23 Jul 2018 05:48:10 -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 Yinr9wSz0TRX for ; Mon, 23 Jul 2018 05:48:08 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 1276E130E74 for ; Mon, 23 Jul 2018 05:48:08 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id g141-v6so1107298ita.4 for ; Mon, 23 Jul 2018 05:48:07 -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=YDOoUTs3enV9a72wgFSat5k+Yiwg1Jb6MSdjSsnzMbQ=; b=jA2u890Um7T++yuS+aY7x1xuZuhZ3OkoElJcuY7FK4CV3y0/kEXgKFo/aj0pEt6O/y HPTkV8kfpnOhlN4UE/SyDWldpKKCC4qy8nEML+CA8UTp+SQKA76M3HMRkVDxun/GMEMM cilyrcgVPtM+wgZAVd4kl9fB1YwDXgJSy5qQY3ijD14gsQHQXXfYbU9uav+8MwVf1ec0 f0QGgO1BlihfcrOcRbM82l3sg9Mm1Uqvf6OrKReMC/Y1/u1t2CSltt7mOj0MJPwTu4Nf wKkuthJDxN4Pa4haDddTPxOvX4QO/tyyg+Moz3/nsbXpuGYTpcl6FdRNGKWQYLGvh8v6 qXjA== 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=YDOoUTs3enV9a72wgFSat5k+Yiwg1Jb6MSdjSsnzMbQ=; b=Vbwj/TDD9ZQ3lJ2z0WNl3LY3px8qQl/5nDF0Ae6D8C5lHpQbAHe6EzhRc088yz2WrC WtrtWJzTGtwliOZVDBNLKOAVQyKX9ldY9rAEfDatm7bi21Xecc2ZnjlxZ4QmXXCcs7uv nQ8VJiLEVg0CWW18bbqmyybtLYJXRlyfrA7MeTwHBYbheNRvqnCIkdaOfcGwJMr4a44U EJ8Q5LmT2Lxly9RDPv1J/5ezGr/QPeL9Ngg2KrAmK9JHzuz8LwS9LYl/puhhEBgw4hHK qcGM7qcja1zR33tVMmolCWkQPzXpTDH39iKU+Q9F7mGBcdBQ4HnjNaf9scEMxgkIYL8U fMdg== X-Gm-Message-State: AOUpUlG1NPoiwtzurC3yBGTVCiN5DYZ+xFTpAXcFXc5kxNur7dRkiDMB +S+Yde8k1+wLtVqsMEiSjjrgz+XaCKWzA4ckLeiy5Lws X-Google-Smtp-Source: AAOMgpey6hkPkL9lIw9u7b07HN6mRuJMBaIxL2CyFfxh7w8pfjII0rD67Vy0TeJFvXkiAQ0HpYMns1ADvWHeiB9Y3No= X-Received: by 2002:a02:b70b:: with SMTP id g11-v6mr11624526jam.34.1532350087263; Mon, 23 Jul 2018 05:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 05:47:26 -0700 (PDT) In-Reply-To: <013858C6-CFB6-481B-811C-066EBCEE3853@gmail.com> References: <7001.1532128071@localhost> <013858C6-CFB6-481B-811C-066EBCEE3853@gmail.com> From: Ted Lemon Date: Mon, 23 Jul 2018 08:47:26 -0400 Message-ID: To: "R. Atkinson" Cc: Michael Richardson , dnssd Content-Type: multipart/alternative; boundary="0000000000009f8eb10571aa0e91" Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 12:48:10 -0000 --0000000000009f8eb10571aa0e91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of course, one reason that there are no servers is that setting them up and having reliable access to them is punitively difficult. In a world where service discovery and enrollment are easy, we might see a softening of the borders between those two use cases. I'm also not convinced that there's a huge difference between them from our perspective. ISTM that the second model is just the first model with more features enabled. And, by the way, you didn't talk about the model of the corporation that has an IT staff running their network, which AFAIK is still pretty common for larger enterprises. Is that contradicted by your experience? On Sat, Jul 21, 2018 at 2:40 PM, R. Atkinson wrote: > > > > On Jul 20, 2018, at 19:07, Michael Richardson > wrote: > > > > > > R. Atkinson wrote: > >> In these environments, I rarely see any servers within a small > >> business. > > > > So, no (surveillance) cameras, scanners and no shared folders? > > It's just printers, which are passive until you need them. > > With respect to small businesses, > =E2=80=94 I sometimes see scanners. Sometimes this is an all-in-one prin= ter > with integrated fax and scanner. > > =E2=80=94 Often, particularly if there is no (brand-name omitted here) se= rvers, > then there are no shared folders, just USB sticks and email to move > files. > > =E2=80=94 Printers predominate. > > With respect to residential, > =E2=80=94 There are a wider range of mDNS devices, such as streaming medi= a > players, OTA TV DVRs that can stream media, (surveillance) cameras, > and what not. > =E2=80=94 Scanners might appear also, of course, as might fax machines. > > Ran > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000009f8eb10571aa0e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of course, one reason that there are no servers is that se= tting them up and having reliable access to them is punitively difficult.= =C2=A0 =C2=A0In a world where service discovery and enrollment are easy, we= might see a softening of the borders between those two use cases.=C2=A0 = =C2=A0I'm also not convinced that there's a huge difference between= them from our perspective.=C2=A0 =C2=A0ISTM that the second model is just = the first model with more features enabled.=C2=A0 And, by the way, you didn= 't talk about the model of the corporation that has an IT staff running= their network, which AFAIK is still pretty common for larger enterprises.= =C2=A0 =C2=A0Is that contradicted by your experience?

On Sat, Jul 21, 2018 at 2:40 PM, = R. Atkinson <rja.lists@gmail.com> wrote:


> On Jul 20, 2018, at 19:07, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> R. Atkinson <rja.lists@gmail= .com> wrote:
>> In these environments, I rarely see any servers within a small
>> business.
>
> So, no (surveillance) cameras, scanners and no shared folders?
> It's just printers, which are passive until you need them.

With respect to small businesses,
=E2=80=94 I sometimes see scanners.=C2=A0 Sometimes this is an all-in-one p= rinter
=C2=A0 =C2=A0 with integrated fax and scanner.

=E2=80=94 Often, particularly if there is no (brand-name omitted here) serv= ers,
=C2=A0 =C2=A0 =C2=A0then there are no shared folders, just USB sticks and e= mail to move files.

=E2=80=94 Printers predominate.

With respect to residential,
=E2=80=94 There are a wider range of mDNS devices, such as streaming media<= br> =C2=A0 =C2=A0 =C2=A0players, OTA TV DVRs that can stream media, (surveillan= ce) cameras,
=C2=A0 =C2=A0 =C2=A0and what not.
=E2=80=94 Scanners might appear also, of course, as might fax machines.

Ran

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--0000000000009f8eb10571aa0e91-- From nobody Mon Jul 23 08:12:02 2018 Return-Path: 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 DB650130EBA for ; Mon, 23 Jul 2018 08:12:00 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hQbysz5VPuKi for ; Mon, 23 Jul 2018 08:11:58 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 4ABAA12D7F8 for ; Mon, 23 Jul 2018 08:11:58 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id n6-v6so951599qtl.4 for ; Mon, 23 Jul 2018 08:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=qqviJRQ5U9KpaILh43iPkXtTcDj+gGoDYPLlDgvYJdc=; b=pfwl8YL/SYneW6l/V8GkyVcWBVUmlnOza7NnhOM9Dkasgl725oUpl+K9W3/6Apybx5 1N1uiuC0FSWdlbAjIy9LpYE9uWqNYVU/WgK6kBxFIxBVVNSafE9Mr8w9rtwJj0yr8nTD Bu3Z0Um2b1y+od4E2gYxJEAKZbIfQvB0lUZAr/UFYlh/wmsoXjvRTxsRMX6+O/v+7ZJL iaM8tx/TJpFWpAIZa2c34u0qKyq62k+2VWOWSguQ0Vv5N4N2bNo5xh+ESuw2zO24rb8U avTMpz6ohPC1eAxYcecd87XibcBYPikfjznCBM2l9vmjrS1grz0WbA2xHtEDIUWex7bB 5bKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=qqviJRQ5U9KpaILh43iPkXtTcDj+gGoDYPLlDgvYJdc=; b=rlEkZhwn2DNu/llFns7BHyhmmOMppYKTkN+r/fxlU2C1qbRPd0dA5ITvyZ1XIhLWk1 WREl1iUB3IvUgm0yiX99xnFDMuUOxyRT4cwRbi+Tev5830lL4qBR7fQUuR6NtZPhs82y hn0UVBAQHuLWlSokEJ0Rrkg+sQKpNxxDNq1Y6ZcwBurTDLHSe0D6ZzIScFq71qhQmhMG 9FPTCx7bxrxIetV2wE520w21GrgkcOKgc31pkBli0iB5aWc8PwHNhBZPCa17d9LxW5a5 YDoxSDEKQZXCaQ9BQmg/WSz/reolQKRscmarlKWyiij+10uZ2i49QsaLqAny842edc/Y qO1g== X-Gm-Message-State: AOUpUlE1nMTdgY1RYIX9tWRcUEju0cDmMkj/8J/xOy0Tz9sJzTUgi/1m SRBfCJTuDAod2a3uY0byH3lLW41I X-Google-Smtp-Source: AAOMgpflrqc9g9rUmq8FvtHiPMkKH3dRN8PyzagqGsInWIx3TUsSqlBsmy1pfV2uv/8J7ulPeHhnEQ== X-Received: by 2002:a0c:86f3:: with SMTP id 48-v6mr11449866qvg.165.1532358716972; Mon, 23 Jul 2018 08:11:56 -0700 (PDT) Received: from [10.30.20.8] (pool-108-18-149-37.washdc.fios.verizon.net. [108.18.149.37]) by smtp.gmail.com with ESMTPSA id r62-v6sm6990045qkl.85.2018.07.23.08.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 08:11:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "R. Atkinson" In-Reply-To: Date: Mon, 23 Jul 2018 11:11:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50ADA039-0AC2-4792-BE13-720F535A2F5E@gmail.com> References: <7001.1532128071@localhost> <013858C6-CFB6-481B-811C-066EBCEE3853@gmail.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:12:01 -0000 > On Jul 23, 2018, at 08:47, Ted Lemon wrote: >=20 > Of course, one reason that there are no servers is that setting them = up > and having reliable access to them is punitively difficult. =20 Yes, but the killer part of this is that none of the =E2=80=9Centerprise = servers=E2=80=9D (for whatever network services seem to be common) are really easy=20 to configure and deploy, as near as I can tell. All of them require some kind of IT staff (or at least a reasonably technical person). =20 Typical residences (again, not IETF participants) and small businesses generally don=E2=80=99t have even one technical person. I expect % of = technical folks with complex residences will vary in some geographies=20 (e.g. Silicon Valley, RTP NC, Kanata ON), of course. > In a world where service discovery and enrollment are easy, we might = see > a softening of the borders between those two use cases. =20 We could. I=E2=80=99m not so sure since my 2nd use case (Large = Enterprise) has IT staff and deploys various kinds of servers already, while the 1st use = case lacks IT staff and doesn=E2=80=99t today deploy servers. =20 =46rom what I am seeing, I think the big barrier to local server = deployment is the knowledge required to correctly deploy a local server. This is a = big issue whether its a DNS server or some other kind of server (e.g. = SMTP/POP). Some company could make good money by creating an IT server that is MUCH MUCH easier to deploy, configure, and update/maintain. If I were still building routers, I=E2=80=99d be looking at DNS-SD as a = differentiation opportunity for enterprise customers. Adding some kind of DNS-SD cache/proxy/enrollment capability likely would sell well and should be practical to implement. Some existing enterprise routers already have=20= a (traditional / unicast) DNS proxy / DNS resolver built-in, so adding=20= support for mDNS caching/proxying and/or DNS-SD enrollment=20 would not be a huge leap. For residences or small businesses, that sort of capability likely would = need=20 to be added into a CPE router provided by the ISP before it would become=20= much easier to deploy inside the home or small business. Even if this = happened, due to CPE router enhancements, it is not clear that the deployment = would go=20 beyond =E2=80=9C.local=E2=80=9D or similar. Put another way, it still = would be unlikely to include=20 a global-scope DNS FQDN. > I'm also not convinced that there's a huge difference between them = from our perspective. ISTM that the second model is just the first = model with more features enabled. =20 What is the meaning of "ISTM" ?? The two cases quoted below both fall into the 1st case for my note from 20 July 2018 @ 12:44 US EDT. > And, by the way, you didn't talk about the model of the corporation = that has an > IT staff running their network, which AFAIK is still pretty common for = larger=20 > enterprises. =20 Yes, I did. It is Case 2 in my note from 20 July 2018 @ 12:44 US EDT. For example, note my use of the phrase =E2=80=9CIT staff=E2=80=9D in the = 3rd paragraph=20 of Case 2.=20 =46rom where I sit, I doubt very much that Case 1 and Case 2 from my note of 20 July will converge anytime soon, which is a good part of why I enumerated them as separate use cases. (Of course, other folks data might vary from mine, so other folks=E2=80=99= =20 perspectives also might vary. :-) Yours, Ran > Is that contradicted by your experience? >=20 > On Sat, Jul 21, 2018 at 2:40 PM, R. Atkinson = wrote: >=20 >=20 > > On Jul 20, 2018, at 19:07, Michael Richardson = wrote: > >=20 > >=20 > > R. Atkinson wrote: > >> In these environments, I rarely see any servers within a small > >> business. > >=20 > > So, no (surveillance) cameras, scanners and no shared folders? > > It's just printers, which are passive until you need them. >=20 > With respect to small businesses,=20 > =E2=80=94 I sometimes see scanners. Sometimes this is an all-in-one = printer > with integrated fax and scanner. >=20 > =E2=80=94 Often, particularly if there is no (brand-name omitted here) = servers, > then there are no shared folders, just USB sticks and email to = move files. >=20 > =E2=80=94 Printers predominate. >=20 > With respect to residential, > =E2=80=94 There are a wider range of mDNS devices, such as streaming = media > players, OTA TV DVRs that can stream media, (surveillance) = cameras,=20 > and what not. > =E2=80=94 Scanners might appear also, of course, as might fax = machines. >=20 > Ran >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Mon Jul 23 09:16:10 2018 Return-Path: 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 91CBA130EF9 for ; Mon, 23 Jul 2018 09:16:08 -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 4beUk07xvfGw for ; Mon, 23 Jul 2018 09:16:05 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 D50D3130DCB for ; Mon, 23 Jul 2018 09:16:04 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g11-v6so1001894ioq.9 for ; Mon, 23 Jul 2018 09:16:04 -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=PEBIdwv2Whtpk0X2PKEN3jOrZcUJRFRT/1s5J1S0qSo=; b=JsLyJob/p/a7Ojad8RapDMPJE5XRVfrxXkNjOfCX12U4OGITMgmP0G7tegQlHB8vO0 otXRSmpD2RqUzK17vTbyE2zVKNvgcFTeuuxGHEGzEZU0o66ITxpJHhAnvXT3MR7VNjMb 6hIUFTEcNGzHkPU8IHfGkf9lv4GJB9SJK6nn/2F6keiSJN9Cc+1by13i75jbKoGOj6og 30YdDLoEyEX1TPjiy1rNLkB4r6zdp/ZBH78j7EB+ZY8Dhr8bUYUWt+Gj3rpnQdOJr67z ft7X9P6N0SBdIXuZZFII7BDiSg4d5IDPD2Mi95EXqaBx9lz7vQSdVPr/4VQxG8WIQTOX CRhQ== 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=PEBIdwv2Whtpk0X2PKEN3jOrZcUJRFRT/1s5J1S0qSo=; b=GpJTYVXkY26/L0eQ5VxufcrUlfLGV/NauXkgn0Af0CRjPJ42jlVLTw8ti+QOU1TZcM ucSWFSLSAkof9rLhdnpjXKE9BncSWfkfHKNFRXI6DZ0sinZl8NpLCrQR7junlmbxA/uQ HyV4vkXbWiSVqzSbiMB8KNlBj9yEAYKGyhxdtE1WbmB0Fc3EiZXwW7HZyT0vtisIKyc/ GuM+LKRrbw4H+kduOIH+MNPm0GCbLIR7eBvCjim/SZSWdy5zBjWMsIGdAdHZHksbvYiG 5HZS5ioWckVaLNI24hruN2VJFWnM2Kr7z9+qS7gUGkYMPmS1ivuu645CIaujfFz4WyqN 3WNA== X-Gm-Message-State: AOUpUlE++p9iPjsAHQzxO8+Bf4Uibk9bDdZ1nSv+ZBFFC68kaQlsx+w1 LE87viyFb3BJjboVA9prEyHgVTMcbFG7sx06DDmMxg== X-Google-Smtp-Source: AAOMgpdH1hs4kdPVvLurRir5MeZkJ4BiEHZYlqLSkGzFjinmpo07Z7gm6ZW1aojZ8CNkuZKTluS3RRFgVl8js69wkkA= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr10571393ioc.45.1532362564077; Mon, 23 Jul 2018 09:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 09:15:23 -0700 (PDT) In-Reply-To: <50ADA039-0AC2-4792-BE13-720F535A2F5E@gmail.com> References: <7001.1532128071@localhost> <013858C6-CFB6-481B-811C-066EBCEE3853@gmail.com> <50ADA039-0AC2-4792-BE13-720F535A2F5E@gmail.com> From: Ted Lemon Date: Mon, 23 Jul 2018 12:15:23 -0400 Message-ID: To: "R. Atkinson" Cc: dnssd Content-Type: multipart/alternative; boundary="0000000000004c98130571acf698" Archived-At: Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:16:09 -0000 --0000000000004c98130571acf698 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ISTM means "It seems to me." I think a global-scope FQDN for the local network that includes the corporation's domain name is quite unlikely, but it's easy to imagine that if it were *useful*, an ISP or a third party might offer it as a service (as with dyndns.org, but delegating a zone rather than just allowing a name to be updated). The benefit for this is simply external reachability of services, so it may be that a better solution would just be a DoH tunnel or VPN tunnel that you could access with the right credentials that would allow you to query home.arpa. It would be nice if this sort of thing could be more automatic, with less user IT fu required. On Mon, Jul 23, 2018 at 11:11 AM, R. Atkinson wrote: > From what I am seeing, I think the big barrier to local server deployment > is the knowledge required to correctly deploy a local server. This is a > big > issue whether its a DNS server or some other kind of server (e.g. > SMTP/POP). > > Some company could make good money by creating an IT server that > is MUCH MUCH easier to deploy, configure, and update/maintain. > We've seen devices like this=E2=80=94they just aren't typical. Your print= er is like this. If you have an Apple Time Machine or Homekit, it's like this. Making devices findable in this way isn't that hard, and enrollment really isn't that hard either. The issue is that right now for most use cases nobody's making devices that work this way. I think that's the barrier to adoption. I don't think that the level of knowledge in the deployment environment is going to up. I hope that the level of knowledge required to deploy will go down. --0000000000004c98130571acf698 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ISTM means "It seems to me."

= I think a global-scope FQDN for the local network that includes the corpora= tion's domain name is quite unlikely, but it's easy to imagine that= if it were useful, an ISP or a third party might offer it as a serv= ice (as with dyndns.org, but delegating a= zone rather than just allowing a name to be updated).=C2=A0 The benefit fo= r this is simply external reachability of services, so it may be that a bet= ter solution would just be a DoH tunnel or VPN tunnel that you could access= with the right credentials that would allow you to query home.arpa.=C2=A0 = =C2=A0It would be nice if this sort of thing could be more automatic, with = less user IT fu required.

On Mon, Jul 23, 2018 at 11:11 AM, R. Atkinson <rja.lists@g= mail.com> wrote:
From wha= t I am seeing, I think the big barrier to local server deployment
is the knowledge required to correctly deploy a local server.=C2=A0 This is= a big
issue whether its a DNS server or some other kind of server (e.g. SMTP/POP)= .

Some company could make good money by creating an IT server that
is MUCH MUCH easier to deploy, configure, and update/maintain.

We've seen devices like this=E2=80=94they just = aren't typical.=C2=A0 =C2=A0Your printer is like this.=C2=A0 =C2=A0If y= ou have an Apple Time Machine or Homekit, it's like this.=C2=A0 =C2=A0M= aking devices findable in this way isn't that hard, and enrollment real= ly isn't that hard either.=C2=A0 =C2=A0The issue is that right now for = most use cases nobody's making devices that work this way.=C2=A0 =C2=A0= I think that's the barrier to adoption.=C2=A0 =C2=A0I don't think t= hat the level of knowledge in the deployment environment is going to up.=C2= =A0 =C2=A0I hope that the level of knowledge required to deploy will go dow= n.=C2=A0
--0000000000004c98130571acf698-- From nobody Tue Jul 24 20:36:47 2018 Return-Path: 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 1E4A0130F67 for ; Tue, 24 Jul 2018 20:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gZvdFLHwgnqA for ; Tue, 24 Jul 2018 20:36:45 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D6FCC130E00 for ; Tue, 24 Jul 2018 20:36:44 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q19-v6so5194346ioh.11 for ; Tue, 24 Jul 2018 20:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ICVUrApWbheJpsBr1mP3XpnWC8FVndaq8NL9mWAfY/k=; b=lq3NBqvQiZE8kO2LVx+CaWVXR34SM5+XC/WKlk8i+0r1XmjjPdkIVph+qWJpXet4rj w6IqpYhsFXvTRfnTe/0r6jBJ3xIvJzuhYicEsCikrxOJ5ShAZ2LjOUASI7I6o+mTj8Z2 k+7BbIHQNNWxDJcOVdS9J/KsFus17juSTVrSPxYqKiovLJDCk+Gs1sVgXgCfuoAMG6k2 i2WES9nOi4wn9CDFrBWwalZTAJQCfnPQis+7aBh5LxYTSty9OtDCsBTrAaFYOjpn65JA 88wwBuHXPd/AwtYi9XQxGtqHHT7mQ5VG9gASRIeoW3Yuxtwg8u8vNyEItxBP/VMOHmpT xKrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ICVUrApWbheJpsBr1mP3XpnWC8FVndaq8NL9mWAfY/k=; b=dOf3blWrzHsexFKNi+cVwjI0/LQ/t0qQAmjwaKDSXt72Dx+f7hBD8PRpWBt55BbL99 BaX+ILFJEBUBtGN8tZ7MxYClAw6j30mvgNMTBijmQpcfGl1V7HCnvofzfQpri8GXcymz Bwv2lknLeT/YUXQ63MTcH6r8iBd/pGDRzkiKzprLcVUCn0B3umXJseoijqavdwPkXCnO JJbyygfNOOOB40P9Y4huIJnMZwYaIuD3gi2j0KWAjwh+OeCGLpVK4iyz6qKL1wxBZqZq m4VGbMrLqZg7tXQP/2bL9gw+ll8BLGT2PSXXUjeq64hT1vnYU+k4D9TrX5vQMoY/YLEu BBVQ== X-Gm-Message-State: AOUpUlHw76VPrgoHv7jnlj41sgi8M/RSb3hO5cly7WpLGkpI/BIYo+Zw zZGHm+d5i86MV6adCi94a6RP2DVcSvu6s5UTm2Po5bNueIkMlg== X-Google-Smtp-Source: AAOMgpdrvGj8p5uWUmqq7ktbj2tS2KKKWpyinckFv1u/TQ+Y0i0E5Fak/NPJlBw519BIN/ihkjYpuQSIkITyJ1n2aik= X-Received: by 2002:a6b:2055:: with SMTP id g82-v6mr15072672iog.204.1532489803884; Tue, 24 Jul 2018 20:36:43 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Tue, 24 Jul 2018 20:36:32 -0700 Message-ID: To: dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dnssd] Reducing Metadata Leakage from Encrypted Files and Communication with PURBs 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 03:36:46 -0000 As promised during the meeting, here's a pointer to the paper which can help reduce the amount of work for discovery request recipients: https://arxiv.org/abs/1806.03160 Best, Chris