Re: [dnssd] Provisional agenda for IETF98

Stuart Cheshire <cheshire@apple.com> Sun, 19 March 2017 20:25 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE71293EC for <dnssd@ietfa.amsl.com>; Sun, 19 Mar 2017 13:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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=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 skeEIRNA6E2F for <dnssd@ietfa.amsl.com>; Sun, 19 Mar 2017 13:25:05 -0700 (PDT)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 8AAD01273E2 for <dnssd@ietf.org>; Sun, 19 Mar 2017 13:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489955105; 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=8x6/cW5AnMzF8uV0Fdmpdxpt84Xu33nTbOAMd+ftvxE=; b=GjvHnyGqkYOn8MRdWFEnxDYK+q2X0fHbeB5HGtoKifNw0/n6gwtdgQ1pkpYJdlYK phqJe44pUS9ko2wQx2ln4z4d/ERbEHuQluu0xgVvoKw8b7tjS0YnQDtSnMSl/W61 akFLKF+x16TK+e7/4cvg+56ei+63Gq8qbI2ffqFs49Yaq3QcdmZJdBtnYvdkQa0b Q46Q66Bla8zzfwZxT5KLrUNYEDYiuhaH5I/mvWKg20w0mnB2QQY51cUd/K7TVgYQ 91rfTxvBATHR3SJj12z1njgB1CmL44uLAiEbT4j5blCFJ4Nk/q2x6zhPVY1ap/NC bK4iOQ1D4gMMpR7wkilxjg==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 7F.56.30096.E19EEC85; Sun, 19 Mar 2017 13:25:05 -0700 (PDT)
X-AuditID: 11973e11-0d9ff70000007590-e6-58cee91ee747
Received: from koseret (koseret.apple.com [17.151.62.39]) by relay2.apple.com (Apple SCV relay) with SMTP id 91.52.06512.E19EEC85; Sun, 19 Mar 2017 13:25:02 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.153.50.205] (unknown [17.153.50.205]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ON200DFJWPKZD60@koseret.apple.com>; Sun, 19 Mar 2017 13:25:02 -0700 (PDT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <DCC07B2D-2F03-4B9B-B1C4-82BD442AD4BE@jisc.ac.uk>
Date: Sun, 19 Mar 2017 13:26:04 -0700
Cc: "dnssd@ietf.org" <dnssd@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com>
References: <DCC07B2D-2F03-4B9B-B1C4-82BD442AD4BE@jisc.ac.uk>
To: Tim Chown <Tim.Chown@jisc.ac.uk>, Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FDorKv48lyEwcxLwhbvl85itGi81sdq 0ffzMZsDs8fOWXfZPZYs+cnksfL3FbYA5igum5TUnMyy1CJ9uwSujHW3H7IWfJSv+HdjM2sD Y5tUFyMnh4SAicTtR1fYuxi5OIQE9jJKHF49gxkm8e7ecSaIxCpGiUl3jjGBJHgFBCV+TL7H 0sXIwcEsoC4xZUouRE0rk8SMbbdYQGqEBaQkXq38zAxhG0k8uT+JHcRmE9CSePH5ChuIzSlg JzHl+z02kDksAqoSu45XgYSZgcyrx/pYIGxtiSfvLrBCrLWRWHN+K1irkICtxMzvj8BaRQQ8 Jea+NoY4WVbiyclFLCDnSAhMYJOYc+Ee4wRG4VlIrp6FcPUsJBsWMDKvYhTKTczM0c3MM9JL LCjISdVLzs/dxAgK9el2gjsYj6+yOsQowMGoxMPbcOFchBBrYllxZe4hRmkOFiVx3ulTzkYI CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHTj/r5l5szbbUwJGv7X3ik+F5xyeNnMDnGtPTMu rcyt3VD8P5h7xl077t0PDxdXn79vnLwh4YCGPbdO0L7Spikz9q7eeKVm3YXItnc1+wUbhOv2 WAdNmbNDZYP9q/npM+2v/9+XGlXycqIAR4b98+7m+Rmqc5+zz2s/nByx3N7hzp63Fy/Ve7Ir sRRnJBpqMRcVJwIAvXmh0lYCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUiON1OXVfu5bkIg7Nv1CzeL53FaNF4rY/V ou/nYzYHZo+ds+6yeyxZ8pPJY+XvK2wBzFFcNimpOZllqUX6dglcGetuP2Qt+Chf8e/GZtYG xjapLkZODgkBE4l3944zdTFycQgJrGKUmHTnGBNIgldAUOLH5HssXYwcHMwC6hJTpuRC1LQy SczYdosFpEZYQEri1crPzBC2kcST+5PYQWw2AS2JF5+vsIHYnAJ2ElO+32MDmcMioCqx63gV SJgZyLx6rI8FwtaWePLuAivEWhuJNee3grUKCdhKzPz+CKxVRMBTYu5rY4iTZSWenFzEMoFR YBaSQ2chHDoLydAFjMyrGAWKUnMSK430EgsKclL1kvNzNzGCQrOh0HkH47FlVocYBTgYlXh4 b1w6FyHEmlhWXJl7iFGCg1lJhHfDQ6AQb0piZVVqUX58UWlOavEhRmkOFiVx3v4jQCmB9MSS 1OzU1ILUIpgsEwenVANjTfbf66tTndafzVr3K/3SthSuxPceF3TTeZ67bP3QX3yTYaPejn8e Rbc+LT3wMz6Qd2HHhGLTbWXhGdPYvTnm9GZena5b8XPChvMTa7fXbNTiOj9jjW7835VfeO0Z ZFeZrLEpE1TjFHxnsFDznNWTRQn1LtJPPuz9qBHcIbPlifCmxwpL7Kd1K7EUZyQaajEXFScC AJ9Ed4lJAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ith8SWVyYsJLwegnndWO9Q58BsM>
Subject: Re: [dnssd] Provisional agenda for IETF98
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Mar 2017 20:25:08 -0000

On 14 Mar 2017, at 09:20, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> Hi,
> 
> The provisional agenda for IETF98 is included below. Please let Ralph or I know if you have suggestions for changes or additions.

Thanks Tim. This looks good.

Here is the status as I see it:

1. draft-ietf-dnssd-hybrid (Discovery Proxy) — ready to progress to the IESG.

2. draft-ietf-dnssd-push — ready for WGLC.

3. draft-ietf-dnsop-session-signal — ready for DNSOP WGLC.

Other documents I did not get done by the draft deadline, but really hope to have ready to submit when submissions re-open on Monday 27th. It would not be reasonable to expect people to discuss the content in our Tuesday meeting, but it would be good if I could have a few minutes to draw people’s attention to them.

4. draft-cheshire-dnssd-roadmap — there are many components that make up service discovery, at various levels, and few people really understand how they all fit together. This short overview document is intended to remedy that.

5. Discovery Broker — this is a kind of meta Discovery Proxy. From the outside it looks like a basic Discovery Proxy. Except, it doesn’t get its answers by querying using Multicast; it gets its answers by querying other Discovery Proxies. It has two purposes. One is client efficiency. Instead of a client opening three Push connections to three Discovery Proxies on three different links, the client can open a single Push connection to a Discovery Broker, which has its own connections to the relevant Discovery Proxies, and aggregates the results for the client. The second purpose is infrastructure efficiency. Instead of a thousand clients all opening separate Push connections to a poor little overloaded router on the link, the thousand clients can open Push connections to a big-iron Discovery Broker in the data centre, which has a single connection to the actual Discovery Proxy embedded in the router on the link. That way, the router on the link only has to serve a single client — the Discovery Broker.

6. Sleep Proxy — Apple has shipped this for years; I need to document it. It’s basically DNS Update, plus garbage collection, plus Wake-on-LAN magic packet. Simple, but should be documented.

7. Advertising Proxy — this allows a device, with appropriate security, to advertise services via multicast service discovery, on a physical link to which the device is not directly attached. It has applicability for mesh networks like 6LoWPAN, where the trusted devices are conceptually part of the network, but can’t themselves use multicast. There have been efforts to support multicast on mesh networks, but this may be an overly heavyweight solution if there’s a better way to advertise services without requiring the mesh to support multicast in its full generality. It’s basically Sleep Proxy without the Wake-on-LAN magic packet.

8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”

Stuart Cheshire