From nobody Mon Apr 15 10:07:23 2019 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 D6BA51203C1 for ; Mon, 15 Apr 2019 10:07:21 -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 29u7zWgzA19h for ; Mon, 15 Apr 2019 10:07:19 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 2D92D1203B0 for ; Mon, 15 Apr 2019 10:07:19 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id z9so8873404pgu.10 for ; Mon, 15 Apr 2019 10:07:19 -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=lkZHWWt4azfScTulEDk3Y3l7NxSJdMn04Tu618YARmE=; b=E3egv7YyPXRiXT/AuEbyI482lJl6gNp3TkOs3wKjmbSesSjGnrlcegkZtlW+pO23z6 2Bs4jsyIpJJPNkhljiKwWGqGuH4PveikHFSBKOCI1bCk6VbNyuB8hSdSgEIjrfZ3njt2 yNI7EF7KKUercJY56UiRrusw5byf9WBJ+z2jAE25VPM6/WuMDcF3TdogEMP6e/VGOMRs RgkfsFscHeUw6wIq3F1bSVKuY7wpQs/A2cd1qww5DbrSFypGGdt3nXQsfc1wSCe5eW5h C/+CeluYar4Ws1dN73JdPGMiELGSIGh5NMD6zKhllonKtqZIM2UW9pu14YjRO3gYRgoN cCug== 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=lkZHWWt4azfScTulEDk3Y3l7NxSJdMn04Tu618YARmE=; b=ULL8qpeTT/kleJ5JwWXi0e9umJIUmAEqLglv58Gl9LQnR0jKgQbFH4G3xuLZIbRtsr 6HYAhTKaK+azkq8zDjpgJcmWYU+wslUVtUAPI/Xz5xaRFT8ULSJrzisMBIHfy5KNwUB/ R1jPhWIpWBxiMASVQROy1pMHsplZVwicKcRCUc/Of87srkhz/1668c7c4wOlfqcK8SfM 1pBOLUp5IYA+cXb2DAS8Y+XUNMaV7tvDVrxxnNa68AXZ/cSlbki/jVgmieP5BUhvWUrH O9g+z/ufo2pIG7sWozxRNPSjlv0HrSxYgLlvn9iG+MT4eUX47h27utQpkVm2TDxtKnkj nJpQ== X-Gm-Message-State: APjAAAUvcokSuFVe3/9LjfRcWTzUYyeccCSPEcrakPL9t9yL4p3kbJ1g YwgrtFCLpryjtFp9iuIP9ieoHF6KQ7AYYq4G/MntZBxW X-Google-Smtp-Source: APXvYqxoMFgnX5gXr65eUHFKYxIqXYxvzEalfDWQcbtNJX7Zh3BbKa/TIchouWYyB37JG5rX01fJ9sZq67YJ5z2OXp4= X-Received: by 2002:aa7:9116:: with SMTP id 22mr77300742pfh.165.1555348038412; Mon, 15 Apr 2019 10:07:18 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Mon, 15 Apr 2019 10:07:07 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="00000000000054ee84058694af08" Archived-At: Subject: [dnssd] WGLC for draft-ietf-dnssd-push X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 17:07:22 -0000 --00000000000054ee84058694af08 Content-Type: text/plain; charset="UTF-8" Hi everyone, This email starts another Working Group Last Call (WGLC) for draft-ietf-dnssd-push, which will last for two weeks until 2019-04-29. As a reminder, this document has already passed WGLC but some slight changes to the document warranted another WGLC. Stuart, please reply here with the list of changes made since the previous WGLC. Everyone else, please raise any concerns in response to this email. Thanks, David --00000000000054ee84058694af08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

This emai= l starts another Working Group Last Call (WGLC) for=C2=A0draft-ietf-dnssd-p= ush, which will last for two weeks until 2019-04-29. As a reminder, this do= cument has already passed WGLC but some slight changes to the document warr= anted another WGLC.

Stuart, please reply here with= the list of changes made since the previous WGLC.

Everyone else, please raise any concerns in response to this email.
<= div>
Thanks,
David
--00000000000054ee84058694af08-- From nobody Mon Apr 15 10:07:30 2019 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 06CFC1203B0 for ; Mon, 15 Apr 2019 10:07:23 -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 GXinQOActRaB for ; Mon, 15 Apr 2019 10:07:21 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 3987A1203B3 for ; Mon, 15 Apr 2019 10:07:21 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id z5so8917689pfn.3 for ; Mon, 15 Apr 2019 10:07:21 -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=eBXlG9zLWjJNkOHzbglTSrnYVsDD526wS7ClG1ewweA=; b=PbwTqfXleMhCzXkVPZ7q1Hcv0XCdb9hwwM6oIi8Yu7KCvd0OxY8+dAl4GgNn3XplFB cbLQ0cANG8LSVn7yKeuXEqstJjU9N8riGO3VJF6UmTEfOampHi3n9B13Y9m+iRRK2J+H xqgZ3KEkNie3e7UeUE4yuVmz+2AZi19V3Ur0yw+DxWLyNAEbMkIrOEqV53bqyH7Ur4hb YeQ/tDR34l6nKeDJ2xMlBNNZdw4K8zPD9cbgUDNfa45JkS7RLlV/eCW3+ylVSlYuckOw uvX+JWmR8qpvLgycwsdO0qKdj4j0D/B7LuuOt/2cadiX32DQ9+LicgyIk9jyd6H/UCCC dXdg== 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=eBXlG9zLWjJNkOHzbglTSrnYVsDD526wS7ClG1ewweA=; b=E+DBF2FloC+qG6oSMKNZ1ZiU3VOKa7j24tiNeoQWRRj60+tUwQlajT3D+EH++sGge0 O9mqUPq1IenBfjKXFvPx6/n3/QJeLxRvaioy8JaEcoo9Cmh0YH94LURm+QVuN4BBRPdp BwutgOqKJFjKJEZt2GqPRZTJYid8iKYwGvAG7tU9BpZaKWQ4fTeq0mj1X0WucLCqILNy 6tbXyQbroxZSIkhI7NoIoZRxsXrhcdnu1IRjEjjkgZfsRNlMtbUQFo6x3NjA6hRs2HLg +4OWx/Thu/WMa0O77D5kfInOHt6cPc8u2dZEwvP33O1EDkUvwsrALgzA42DqEjqkfKbh lMAA== X-Gm-Message-State: APjAAAXO+mwJZLnjPE19CIhOdELBcB5l2WHtD6y628T4u7FpE5qw2wDs FNQwufQgU318lcC2fFXcf685+CsfayU7apr/WmCaxait X-Google-Smtp-Source: APXvYqwJBMw5AHwqdf8J0HXATProiW60EzyBYvpx2XU5bp9ytDser5zY1ZGBiAMDGXVtq7F1EppwAVcLLH4AkJvldRs= X-Received: by 2002:a62:5fc7:: with SMTP id t190mr29228887pfb.191.1555348040587; Mon, 15 Apr 2019 10:07:20 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Mon, 15 Apr 2019 10:07:09 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000762094058694af0b" Archived-At: Subject: [dnssd] WGLC for draft-ietf-dnssd-mdns-relay X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 17:07:23 -0000 --000000000000762094058694af0b Content-Type: text/plain; charset="UTF-8" Hi everyone, This email starts a Working Group Last Call (WGLC) for draft-ietf-dnssd-mdns-relay, which will last for two weeks until 2019-04-29. As a reminder, the last WGLC failed due to lack of statements of support. Please indicate support or raise any concerns in response to this email. Thanks, David --000000000000762094058694af0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

This emai= l starts a Working Group Last Call (WGLC) for=C2=A0draft-ietf-dnssd-mdns-re= lay, which will last for two weeks until 2019-04-29. As a reminder, the las= t WGLC failed due to lack of statements of support.

Please indicate support or raise any concerns in response to this email.<= /div>

Thanks,
David
--000000000000762094058694af0b-- From nobody Mon Apr 15 10:07:35 2019 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 BBC1C1203F1 for ; Mon, 15 Apr 2019 10:07:24 -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 JIfRenTP9hjb for ; Mon, 15 Apr 2019 10:07:23 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 08C211203C1 for ; Mon, 15 Apr 2019 10:07:23 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id f36so8880140plb.5 for ; Mon, 15 Apr 2019 10:07:23 -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=umX7/S+wcbQ35QH5qyNq8evh/XRsIJeZ5vEw0vMZUJA=; b=cM1zWbcCNk9k4DYlUsVJ5NOPlk915ZNd2K8kKxVrD40p3rOaNg6RnR7pHf+GVVvS49 N6UE1AkHEXo3nSG46Mbc3p6UwTXZsPGejsPa73fK6HvY/Ib+bSzDpTQB8w/9uY6n/bTa QTDUKxCrNYAzBP6zS8XZLjAsYhP0edAW6HH3+nf38D2CEwhs98mcKsYjBlg3nGRflfWH LpliGXrIWT9Y6OaVUKnZLBshfiMzkgDD+g+BHuBsm5bW1IuJsy47gUnzH4oo1pMn/Ca4 enQ1OkSm79L19Wvk+qU6a5xKmHExUl5lOHHjl360y7z7PENIykeSf7jqR6WP8JKtstlm 1/+g== 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=umX7/S+wcbQ35QH5qyNq8evh/XRsIJeZ5vEw0vMZUJA=; b=AQjOwzUI3U0mG4k8fDD0D19Z1WBmAweMhjYKGP7wA5AIsN5Zl4aqyewO2XaSLf9Sv1 vycI6NSJDN9t7CfRSQ4Hf/PaymxZx4zXFcfXKVEXVXlcihzpshMPqrRpdD0v8sxW+GeI ZSXqD0HMmA9dXdc5PhuhzG6qjSDUQ0LWLG3bPPVZ3ga/N9Luqvgy6hW/8i/OcbqEVq8c PAL4BXYHG0yo3x7HRN/i7WLfSEMGLNrRLZbiNNGpnxUf+mOCu6DuaGzSLiAXtzj4iN1l bj5nt3rgxbuV5sL7KV0hsj4ytomATp4EmDpA63KzldVKJuaM8Mbz1YZ9FV5JL+5RM2kI ekWg== X-Gm-Message-State: APjAAAW0E4NQ/P1HkkjZ2i17VdA0eRVL1oV5LIN/5r+7lzE4gmXYWkKI v0LrZog6Uuw1KGyAJcAflVAFr1uWn5RF8YLLKNE2hMeb X-Google-Smtp-Source: APXvYqxc1YPVyuyd1noqSfpqRMMSPCC4mwRqiiCmAN4vN+pja3WZ8FYSOjm6PZRRRqpItrXFGbh7M8Du1yhugPQNcLE= X-Received: by 2002:a17:902:7d8f:: with SMTP id a15mr43026342plm.3.1555348042437; Mon, 15 Apr 2019 10:07:22 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Mon, 15 Apr 2019 10:07:11 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000925a97058694afcb" Archived-At: Subject: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 17:07:26 -0000 --000000000000925a97058694afcb Content-Type: text/plain; charset="UTF-8" Hi everyone, This email starts a Working Group Last Call (WGLC) for draft-ietf-dnssd-srp, which will last for two weeks until 2019-04-29. Please indicate support or raise any concerns in response to this email. Thanks, David --000000000000925a97058694afcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

This emai= l starts a Working Group Last Call (WGLC) for=C2=A0draft-ietf-dnssd-srp, wh= ich will last for two weeks until 2019-04-29.

Plea= se indicate support or raise any concerns in response to this email.
<= div>
Thanks,
David
--000000000000925a97058694afcb-- From nobody Thu Apr 25 09:41:25 2019 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 0C1EB120171; Thu, 25 Apr 2019 09:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dschinazi.ietf@gmail.com, dnssd@ietf.org, dnssd-chairs@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155621048104.881.3721282676381505405.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 09:41:21 -0700 Archived-At: Subject: [dnssd] dnssd - New Meeting Session Request for IETF 105 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 25 Apr 2019 16:41:21 -0000 A new meeting session request has just been submitted by David Schinazi, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: David Schinazi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: dnsop doh dprive homenet quic tls babel intarea httpbis Second Priority: mls core anima People who must be present: Eric Vyncke Barbara Stark David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Apr 25 22:13:53 2019 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 7B23C1200B8 for ; Thu, 25 Apr 2019 22:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=email.apple.com header.b=B8VdzwxZ; dkim=pass (2048-bit key) header.d=apple.com header.b=GofkFZJq 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 JrZCCPoVfbcc for ; Thu, 25 Apr 2019 22:13:43 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 B5546120137 for ; Thu, 25 Apr 2019 22:13:42 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x3Q57T5k012167 for ; Thu, 25 Apr 2019 22:13:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email.apple.com; h=mime-version : content-type : sender : from : subject : date : references : to : in-reply-to : message-id; s=20190418; bh=9FF0nFSd5Z3wC396T7srU3LPHeDsBlNFLA3cw6T2mUo=; b=B8VdzwxZuRsfnJn3zx2yHXngxmbO/vPxVkxvfx6A4x1JE8Z6RM8jh5CT3dX9MqLL1AcP uMBG+xDnVaIZnSoG0oW3SYQb6KHYOo6uCFiteFqqtyFk55ynSzaRTX3MYcR3XH3XrJpW jgUAnMM3d6bZCapS8yTmabOVB9JSIuAknnTuflLQLN6B9It/pLV29OdGLGROk9gmRRbx G6Ugye7w9QCBjpX1eP1EX2ByvRlckmHvQ92QtQoST1EiEkNiCv8SEH0C6jAKz5i/F8fZ GImK84I7Jgiv7/G7YR3W+6gPSgM6b4PFSoOdfk31dE4agAxpVouN6Rfrkp2S0FSOmKij mA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=9FF0nFSd5Z3wC396T7srU3LPHeDsBlNFLA3cw6T2mUo=; b=GofkFZJqjZhEK8HxrmpV5pKbi9rnKTMW6/TuZH5+BB0mixbsPNsuz00dtVnNJTJx8VQs k2a54YkBp6MqxgIvCumR/w/YguORn06jPYKhm2flH+lUgWXjHYCRLcWFqcknV0DGVoqv D2oFvHOiB0FdI3OHYfgefQTCl1DjsBsFwnqzy9iQVgkUPY42bXP5oTComdZOK4Q+ESOH elQQYcXMvrXCsaMt+pfieEn4AJrXpfQAarMMqhPZBkvCcjBl/CVrNjrcubN1BRASAWev qlVKvda3VSFwn1V+hGc0QvxBNCdUmQMbm2YH0ehEtHs+pI9clLLkNUz2aLR9fEaWzvdM Zw== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2s1sc1mqh3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 25 Apr 2019 22:13:40 -0700 MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Wq1XeBIaw82Bwu0++WUYSg)" Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PQJ009K0YIQ6AA0@mr2-mtap-s02.rno.apple.com> for dnssd@ietf.org; Thu, 25 Apr 2019 22:13:39 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PQJ00100XXOUE00@nwk-mmpp-sz11.apple.com> for dnssd@ietf.org; Thu, 25 Apr 2019 22:13:39 -0700 (PDT) X-Va-A: X-Va-T-CD: 67f481029bce65efa0808f4eee5f1f07 X-Va-E-CD: 448a8d71df449d92dc21697bc2e97da2 X-Va-R-CD: 65fc0d991785644c4fa4fe0d67bafe62 X-Va-CD: 0 X-Va-ID: 70a7ffae-83d3-484d-b703-f32927db8615 X-V-A: X-V-T-CD: 67f481029bce65efa0808f4eee5f1f07 X-V-E-CD: 448a8d71df449d92dc21697bc2e97da2 X-V-R-CD: 65fc0d991785644c4fa4fe0d67bafe62 X-V-CD: 0 X-V-ID: 7503306c-c6a1-4033-b3b0-025342bece59 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-26_03:,, signatures=0 Received: from [17.234.124.190] (unknown [17.234.124.190]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PQJ00FQZYIM7Y50@nwk-mmpp-sz11.apple.com> for dnssd@ietf.org; Thu, 25 Apr 2019 22:13:35 -0700 (PDT) Sender: cheshire@apple.com From: Stuart Cheshire Date: Thu, 25 Apr 2019 22:13:33 -0700 References: To: DNSSD In-reply-to: Message-id: <19C8C2DA-8B57-44B2-9457-DCB395D95D62@apple.com> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-26_03:, , signatures=0 X-Proofpoint-AD-Result: none Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-push X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 26 Apr 2019 05:13:52 -0000 --Boundary_(ID_Wq1XeBIaw82Bwu0++WUYSg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable On 15 Apr 2019, at 10:07, David Schinazi = wrote: > This email starts another Working Group Last Call (WGLC) for = draft-ietf-dnssd-push, which will last for two weeks until 2019-04-29. = As a reminder, this document has already passed WGLC but some slight = changes to the document warranted another WGLC. Thank you David. I have attached an HTML file of the output from = comparing draft-ietf-dnssd-push-16 with = draft-ietf-dnssd-push-19. There are a variety of minor textual changes, such as replacing = references to draft-ietf-dnsop-session-signal with references to RFC = 8490, now that this document is published. In terms of substantive changes, there are two: 1. DNS Push Notification RECONFIRM We realized that there is no useful response to a RECONFIRM request. We = changed RECONFIRM to be a unidirectional DSO message, and that results = in the deletion of the entire =E2=80=9CRECONFIRM Response=E2=80=9D = section. This simplifies both code, and the document. 2. DNS Push Notification Updates Previously, Tom Pusateri and I thought that borrowing the DNS Update = encoding made sense. That was before DSO (RFC 8490). When implementing the current specification of DNS Push Notifications = over DSO, Ted Lemon discovered that it has no way to express the DNS = CLASS of changes. We need to address the problem Ted Lemon discovered, and now that DNS = Push uses DSO TLV encoding instead of traditional DNS messages, the = incentive to follow strictly the existing DNS Update encoding has = disappeared. To address this issue, we adopted a new, simpler, way of expressing = changes. It=E2=80=99s broadly similar, but simpler. Please take a look at these changes and let us know if you see any = problems. And if you *don=E2=80=99t* see any problems with these changes, please = respond saying that too. Stuart Cheshire --Boundary_(ID_Wq1XeBIaw82Bwu0++WUYSg) Content-type: text/html; x-unix-mode=0644; name="Diff_ draft-ietf-dnssd-push-16.txt - draft-ietf-dnssd-push-19.txt.htm" Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename*0="Diff_ draft-ietf-dnssd-push-16.txt - dra"; filename*1=ft-ietf-dnssd-push-19.txt.htm =20 =20 =20 Diff: draft-ietf-dnssd-push-16.txt - = draft-ietf-dnssd-push-19.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = = = = = = = = = =
< draft-ietf-dnssd-push-16.txt  =  draft-ietf-dnssd-push-19.txt >
=
Internet = Engineering Task Force T. Pusateri = Internet Engineering Task Force = T. Pusateri
Internet-Draft = Unaffiliated Internet-Draft = Unaffiliated
Intended status: = Standards Track S. Cheshire = Intended status: Standards Track = S. Cheshire
Expires: May 9, 2019 = Apple Inc. Expires: September 25, 2019 = Apple Inc.
= November = 5, 2018 = March 24, = 2019
=
= DNS Push Notifications = DNS Push Notifications
= draft-ietf-dnssd-push-16 = = draft-ietf-dnssd-push-19
=
Abstract = Abstract
=
The Domain = Name System (DNS) was designed to return matching records = The Domain Name System (DNS) was designed to = return matching records
efficiently = for queries for data that are relatively static. When efficiently for queries for data that are relatively = static. When
those records = change frequently, DNS is still efficient at returning those records change frequently, DNS is still = efficient at returning
the updated = results when polled, as long as the polling rate is not = the updated results when polled, as long as = the polling rate is not
too high. But = there exists no mechanism for a client to be too high. But there exists no mechanism for a client = to be
asynchronously = notified when these changes occur. This document asynchronously notified when these changes occur. = This document
defines a = mechanism for a client to be notified of such changes to = defines a mechanism for a client to be = notified of such changes to
=
skipping to = change at = page 1, line 38 =C2=B6 = skipping to change at page 1, line 38 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 9, = 2019. This Internet-Draft will = expire on September 25, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2018 IETF Trust and the persons = identified as the Copyright (c) = 2019 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
=
skipping to = change at = page 2, line 19 =C2=B6 = skipping to change at page 2, line 19 =C2=B6
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
1.1. = Requirements Language . . . . . . . . . . . . . . . . . . 3 = 1.1. Requirements Language . . . . . . . = . . . . . . . . . . . 3
2. Motivation = . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . = . . . . . . 4
3. Overview = . . . . . . . . . . . . . . . . . . . . . . . . . . 5 = 3. Overview . . . . . . . . . . . . . . . = . . . . . . . . . . . 5
4. Transport = . . . . . . . . . . . . . . . . . . . . . . . . . . 7 = 4. Transport . . . . . . . . . . . . . . . = . . . . . . . . . . . 7
5. State = Considerations . . . . . . . . . . . . . . . . . . . . 8 = 5. State Considerations . . . . . . . . . = . . . . . . . . . . . 8
6. Protocol = Operation . . . . . . . . . . . . . . . . . . . . . 9 = 6. Protocol Operation . . . . . . . . . . = . . . . . . . . . . . 9
6.1. = Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 = 6.1. Discovery . . . . . . . . . . . . . = . . . . . . . . . . . 10
6.2. DNS = Push Notification SUBSCRIBE . . . . . . . . . . . . . 13 6.2. = DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 14
6.2.1. = SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 = 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 14
6.2.2. = SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16 = 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 17
6.3. DNS = Push Notification Updates . . . . . . . . . . . . . . 19 6.3. = DNS Push Notification Updates . . . . . . . . . . . . . . 20
6.3.1. = PUSH Message . . . . . . . . . . . . . . . . . . . . 19 = 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20
6.4. DNS = Push Notification UNSUBSCRIBE . . . . . . . . . . . . 22 6.4. = DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25
6.4.1. = UNSUBSCRIBE Request . . . . . . . . . . . = . . . . . . 22 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25
6.5. DNS = Push Notification RECONFIRM . . . . . . . . . . . . . 24 6.5. = DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27
6.5.1. = RECONFIRM Request . . . . . . . . . . . . . . . = . . . 24 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . = 28
6.5.2. RECONFIRM Response . . . . . . . = . . . . . . . . . . 26 6.6. DNS Stateful Operations TLV Context Summary = . . . . . . . 30
6.6. DNS = Stateful Operations TLV Context Summary . . . . . . . 28 6.7. = Client-Initiated Termination . . . . . . . . . . . . . . 31
6.7. = Client-Initiated Termination . . . . . . . . . . . . . . 29 7. = Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. Security = Considerations . . . . . . . . . . . . . . . . . . . 30 7.1. = Security Services . . . . . . . . . . . . . . . . . . . . 32
7.1. = Security Services . . . . . . . . . . . . . . . . . . . . 30 7.2. = TLS Name Authentication . . . . . . . . . . . . . . . . . 32
7.2. TLS = Name Authentication . . . . . . . . . . . . . . . . . 30 7.3. = TLS Session Resumption . . . . . . . . . . . . . . . . . 33
7.3. TLS = Compression . . . . . . . . . . . . . . . . . . . = . . 31 8. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 33
7.4. TLS Session Resumption . . . . . . . = . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . = . . . . . . . 34
8. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. = References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. = Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10.1. = Normative References . . . . . . . . . . . . . . . . . . 34
10. = References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.2. = Informative References . . . . . . . . . . . . . . . . . 36
10.1. = Normative References . . . . . . . . . . . . . . . . . . 33 = Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. = Informative References . . . . . . . . . . . . . . . . . 34
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
=
1. = Introduction 1. Introduction
=
Domain Name = System (DNS) records may be updated using DNS Update Domain Name System (DNS) records may be updated using = DNS Update
[RFC2136]. = Other mechanisms such as a Discovery Proxy [DisProx] can = [RFC2136]. Other mechanisms such as a = Discovery Proxy [DisProx] can
also generate = changes to a DNS zone. This document specifies a also generate changes to a DNS zone. This document = specifies a
protocol for = DNS clients to subscribe to receive asynchronous protocol for DNS clients to subscribe to receive = asynchronous
notifications = of changes to RRSets of interest. It is immediately notifications of changes to RRSets of interest. It = is immediately
relevant in = the case of DNS Service Discovery [RFC6763] but is not relevant in the case of DNS Service Discovery = [RFC6763] but is not
limited to = that use case, and provides a general DNS mechanism for = limited to that use case, and provides a = general DNS mechanism for
DNS record = change notifications. Familiarity with the DNS protocol = DNS record change notifications. = Familiarity with the DNS protocol
and DNS packet = formats is assumed [RFC1034] [RFC1035] [RFC6895]. and DNS packet formats is assumed [RFC1034] [RFC1035] = [RFC6895].
=
1.1. = Requirements Language 1.1. = Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and = "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT = RECOMMENDED", "MAY", and
"OPTIONAL" in = this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as = described in
"Key words for use in RFCs to Indicate Requirement = Levels", when, and BCP 14 [RFC2119] [RFC8174] when, and only when, = they appear in all
only when, = they appear in all capitals, as shown here = [RFC2119] capitals, as = shown here. These words may also appear in = this
[RFC8174]. document in lower case as = plain English words, absent their normative
= = meanings.
=
2. = Motivation 2. Motivation
=
As the domain = name system continues to adapt to new uses and changes As the domain name system continues to adapt to new = uses and changes
in deployment, = polling has the potential to burden DNS servers at in deployment, polling has the potential to burden = DNS servers at
many levels = throughout the network. Other network protocols have many levels throughout the network. Other network = protocols have
successfully = deployed a publish/subscribe model following the successfully deployed a publish/subscribe model = following the
Observer = design pattern [obs]. XMPP Publish-Subscribe [XEP0060] and = Observer design pattern [obs]. XMPP = Publish-Subscribe [XEP0060] and
Atom [RFC4287] = are examples. While DNS servers are generally highly Atom [RFC4287] are examples. While DNS servers are = generally highly
tuned and = capable of a high rate of query/response traffic, adding a = tuned and capable of a high rate of = query/response traffic, adding a
=
skipping to = change at = page 4, line 30 =C2=B6 = skipping to change at page 4, line 30 =C2=B6
multicast = group address for all group members to receive. Therefore, = multicast group address for all group = members to receive. Therefore,
Multicast DNS = already has asynchronous change notification Multicast DNS already has asynchronous change = notification
capability. = However, when DNS Service Discovery [RFC6763] is used capability. However, when DNS Service Discovery = [RFC6763] is used
across a wide = area network using Unicast DNS (possibly facilitated across a wide area network using Unicast DNS = (possibly facilitated
via a = Discovery Proxy [DisProx]) it would be beneficial to have an = via a Discovery Proxy [DisProx]) it would be = beneficial to have an
equivalent = capability for Unicast DNS, to allow clients to learn equivalent capability for Unicast DNS, to allow = clients to learn
about DNS = record changes in a timely manner without polling. about DNS record changes in a timely manner without = polling.
=
The DNS = Long-Lived Queries (LLQ) mechanism [LLQ] is an existing = The DNS Long-Lived Queries (LLQ) mechanism = [LLQ] is an existing
deployed = solution to provide asynchronous change notifications, used = deployed solution to provide asynchronous = change notifications, used
by Apple's = Back to My Mac Service [RFC6281] = introduced in Mac OS X by Apple's = Back to My Mac [RFC6281] service = introduced in Mac OS X
10.5 Leopard = in 2007. Back to My Mac was designed in an era when the = 10.5 Leopard in 2007. Back to My Mac was = designed in an era when the
data center = operations staff asserted that it was impossible for a data center operations staff asserted that it was = impossible for a
server to = handle large numbers of mostly-idle TCP connections, so LLQ = server to handle large numbers of = mostly-idle TCP connections, so LLQ
was defined as = a UDP-based protocol, effectively replicating much of was defined as a UDP-based protocol, effectively = replicating much of
TCP's = connection state management logic in user space, and creating = TCP's connection state management logic in = user space, and creating
its own poor = imitations of existing TCP features like the three-way its own poor imitations of existing TCP features like = the three-way
handshake, = flow control, and reliability. = handshake, flow control, and reliability.
=
This document = builds on experience gained with the LLQ protocol, with = This document builds on experience gained = with the LLQ protocol, with
an improved = design. Instead of using UDP, this specification uses an improved design. Instead of using UDP, this = specification uses
DNS Stateful = Operations (DSO) [DSO] running over TLS = over TCP, and DNS Stateful = Operations (DSO) [RFC8490] running over = TLS over TCP,
therefore = doesn't need to reinvent existing TCP functionality. Using = and therefore doesn't need to reinvent = existing TCP functionality.
TCP also = gives long-lived low-traffic connections better longevity = Using TCP also gives long-lived low-traffic = connections better
through NAT = gateways without resorting to excessive keepalive longevity through NAT gateways without depending on the gateway to
traffic. = Instead of inventing a new vocabulary of messages = to = support NAT Port Mapping Protocol (NAT-PMP) [RFC6886] or Port = Control
communicate DNS zone changes as LLQ did, this = specification borrows Protocol (PCP) [RFC6887], or resorting to = excessive keepalive
the established syntax and semantics of DNS Update = messages traffic.
[RFC2136].
=
3. = Overview 3. Overview
=
The existing DNS Update protocol [RFC2136] provides a = mechanism for A DNS Push Notification client subscribes for = Push Notifications for
clients to add or delete individual resource records = (RRs) or entire a particular RRSet by connecting to the appropriate Push Notification
resource record sets (RRSets) on the zone's = server. server for that RRSet, and sending DSO message(s) indicating the
RRSet(s) = of interest. When the client loses interest in receiving
This specification adopts a simplified subset of = these existing further = updates to these records, it unsubscribes.
syntax and semantics, and uses them for DNS = Push Notification
messages going in the opposite direction, from server = to client, to
communicate changes to a zone. The client = subscribes for Push
= Notifications by connecting to the server and sending DNS message(s)
indicating = the RRSet(s) of interest. When the client loses interest =
in receiving = further updates to these records, it unsubscribes.
=
The DNS Push = Notification server for a zone is any server capable of = The DNS Push Notification server for a = DNS zone is any server capable
generating = the correct change notifications for a name. It may be a = of generating the correct change = notifications for a name. It may be
primary, = secondary, or stealth name server [RFC7719]. Consequently, = a primary, secondary, or stealth name = server [RFC7719].
the = "_dns-push-tls._tcp.<zone>" SRV record for a zone MAY = reference Consequently, the = "_dns-push-tls._tcp.<zone>" SRV record for a zone
the same = target host and port as that zone's = MAY reference the same target host and port as that zone's
= "_dns-update-tls._tcp.<zone>" SRV record. When the same target = host = "_dns-update-tls._tcp.<zone>" SRV record. When the same target = host
and port is = offered for both DNS Updates and DNS Push Notifications, = and port is offered for both DNS Updates and = DNS Push Notifications,
a client MAY = use a single TCP connection to that server for both DNS = a client MAY use a single TCP connection to = that server for both DNS
Updates and = DNS Push Notification Subscriptions. = Updates and DNS Push Notification Subscriptions.
=
Supporting DNS = Updates and DNS Push Notifications on the same server Supporting DNS Updates and DNS Push Notifications on = the same server
is OPTIONAL. = A DNS Push Notification server does NOT also = have to is OPTIONAL. A DNS = Push Notification server is NOT REQUIRED = also to
support DNS = Update. support DNS Update.
=
DNS Updates = and DNS Push Notifications may be handled on different DNS Updates and DNS Push Notifications may be handled = on different
ports on the = same target host, in which case they are not considered = ports on the same target host, in which case = they are not considered
to be the = "same server" for the purposes of this specification, and = to be the "same server" for the purposes of = this specification, and
communications = with these two ports are handled independently. communications with these two ports are handled = independently.
=
Standard DNS = Queries MAY be sent over a DNS Push Notification Standard DNS Queries MAY be sent over a DNS Push = Notification (i.e.,
connection. For any zone for which the server = is authoritative, it DSO) session. For any zone for which the = server is authoritative, it
MUST respond = authoritatively for queries on names falling within that = MUST respond authoritatively for queries on = names falling within that
zone (e.g., = the <zone> in the "_dns-push-tls._tcp.<zone>" SRV = record) zone (e.g., the = <zone> in the "_dns-push-tls._tcp.<zone>" SRV = record)
both for DNS = Push Notification queries and for normal DNS queries. = both for normal DNS queries and for DNS = Push Notification
For names = for which the server is acting as a caching = resolver, e.g. = subscriptions. For names for which the server is acting as = a
when the = server is the local resolver, for any query for which it = recursive = resolver, e.g. when the server is the local recursive
supports DNS = Push Notifications, it MUST also support = standard resolver, for any query = for which it supports DNS Push Notification
= queries. = subscriptions, it MUST also support standard queries.
= =
DNS Push Notification clients are NOT required to = implement DNS
Update Prerequisite processing. Prerequisites are = used to perform
tentative atomic test-and-set type operations when a = client updates
records on a server, and that concept has no = applicability when it
comes to an authoritative server unilaterally = informing a client of
changes to DNS records.
=
This DNS Push = Notification specification includes support for DNS This DNS Push Notification specification includes = support for DNS
classes, for = completeness. However, in practice, it is anticipated classes, for completeness. However, in practice, it = is anticipated
that for the = foreseeable future the only DNS class in use will be DNS = that for the foreseeable future the only DNS = class in use will be DNS
class "IN", as = is the reality today with existing DNS servers and class "IN", as is the reality today with existing DNS = servers and
clients. A = DNS Push Notification server MAY choose to implement only = clients. A DNS Push Notification server MAY = choose to implement only
DNS class = "IN". If messages are received for a class other than DNS class "IN". If messages are received for a class = other than
"IN", and that = class is not supported, an error with RCODE NOTIMPL "IN", and that class is not supported, an error with = RCODE NOTIMPL
(Not = Implemented) should be returned. = (Not Implemented) should be returned.
=
DNS Push = Notifications impose less load on the responding server than = DNS Push Notifications impose less load on = the responding server than
rapid polling = would, but Push Notifications do still have a cost, so rapid polling would, but Push Notifications do still = have a cost, so
DNS Push = Notification clients must not recklessly = create an excessive DNS Push = Notification clients MUST NOT recklessly = create an excessive
number of Push = Notification subscriptions. Specifically: number of Push Notification subscriptions. = Specifically:
=
(a) A = subscription should only be active when there is a valid reason = (a) A subscription should only be active = when there is a valid reason
to need live = data (for example, an on-screen display is currently to need live data (for example, an on-screen display = is currently
showing the = results to the user) and the subscription SHOULD be showing the results to the user) and the subscription = SHOULD be
cancelled as = soon as the need for that data ends (for example, when cancelled as soon as the need for that data ends (for = example, when
the user = dismisses that display). Implementations may = want to the user dismisses = that display). In the case of a device like = a
implement idle timeouts, so that if the user ceases interacting with smartphone which, after some = period of inactivity, goes to sleep = or
the device, the subscription = is cancelled. otherwise darkens its screen, it should cancel its = subscriptions when
= darkening the = screen (since the user cannot see any changes in the
= display anyway) and = reinstate its subscriptions when re-awakening
= from display = sleep.
=
(b) A DNS Push = Notification client SHOULD NOT routinely keep a DNS (b) A DNS Push Notification client SHOULD NOT = routinely keep a DNS
Push = Notification subscription active 24 hours a day, 7 days a week, = Push Notification subscription active 24 = hours a day, 7 days a week,
just to keep a = list in memory up to date so that if the user does just to keep a list in memory up to date so that if = the user does
choose to = bring up an on-screen display of that data, it can be choose to bring up an on-screen display of that data, = it can be
displayed = really fast. DNS Push Notifications are designed to be = displayed really fast. DNS Push = Notifications are designed to be
fast enough = that there is no need to pre-load a "warm" list in memory = fast enough that there is no need to = pre-load a "warm" list in memory
just in case = it might be needed later. just in = case it might be needed later.
=
Generally, as = described in the DNS Stateful Operations specification Generally, as described in the DNS Stateful = Operations specification
[DSO], a client must not keep a session to a = server open indefinitely [RFC8490], a client must not keep a session to a = server open
if it has no = subscriptions (or other operations) active on that indefinitely if it has no subscriptions (or other = operations) active
session. A = client MAY close a session as soon as it becomes idle, on that session. A client MAY close a session as = soon as it becomes
and then if = needed in the future, open a new session when required. = idle, and then if needed in the future, = open a new session when
= Alternatively, a client MAY speculatively keep an idle session = open required. Alternatively, a = client MAY speculatively keep an idle
for some = time, subject to the constraint that it MUST NOT keep a = session open for some time, subject to the = constraint that it MUST
session open = that has been idle for more than the session's idle NOT keep a session open that has been idle for more = than the
timeout (15 = seconds by default). session's idle timeout (15 seconds by default) [RFC8490].
=
4. = Transport 4. Transport
=
Other DNS = operations like DNS Update [RFC2136] MAY use either User = Other DNS operations like DNS Update = [RFC2136] MAY use either User
Datagram = Protocol (UDP) [RFC0768] or Transmission Control Protocol = Datagram Protocol (UDP) [RFC0768] or = Transmission Control Protocol
(TCP) = [RFC0793] as the transport protocol, in keeping with the = (TCP) [RFC0793] as the transport protocol, = in keeping with the
historical = precedent that DNS queries must first be sent over UDP historical precedent that DNS queries must first be = sent over UDP
[RFC1123]. = This requirement to use UDP has subsequently been relaxed = [RFC1123]. This requirement to use UDP has = subsequently been relaxed
= [RFC7766]. [RFC7766].
=
In keeping = with the more recent precedent, DNS Push Notification is = In keeping with the more recent precedent, = DNS Push Notification is
defined only = for TCP. DNS Push Notification clients MUST use DNS defined only for TCP. DNS Push Notification clients = MUST use DNS
Stateful = Operations (DSO) [DSO] running over TLS = over TCP [RFC7858]. Stateful = Operations [RFC8490] running over TLS over = TCP [RFC7858].
=
Connection = setup over TCP ensures return reachability and alleviates = Connection setup over TCP ensures return = reachability and alleviates
concerns of = state overload at the server through anonymous concerns of state overload at the server through = anonymous
subscriptions. = All subscribers are guaranteed to be reachable by the subscriptions. All subscribers are guaranteed to be = reachable by the
server by = virtue of the TCP three-way handshake. Flooding attacks = server by virtue of the TCP three-way = handshake. Flooding attacks
are possible = with any protocol, and a benefit of TCP is that there are possible with any protocol, and a benefit of TCP = is that there
are already = established industry best practices to guard against SYN = are already established industry best = practices to guard against SYN
flooding and = similar attacks [SYN] [RFC4953]. = flooding and similar attacks [SYN] [RFC4953].
=
Use of TCP = also allows DNS Push Notifications to take advantage of = Use of TCP also allows DNS Push = Notifications to take advantage of
current and = future developments in TCP, such as Multipath TCP (MPTCP) = current and future developments in TCP, such = as Multipath TCP (MPTCP)
[RFC6824], TCP = Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss = Probe (TLP)
= [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. [I-D.dukkipati-tcpm-tcp-loss-probe], and so = on.
=
Transport = Layer Security (TLS) [RFC5246] is well = understood and Transport Layer = Security (TLS) [RFC8446] is well = understood and
deployed = across many protocols running over TCP. It is designed to = deployed across many protocols running over = TCP. It is designed to
prevent = eavesdropping, tampering, and message forgery. TLS is prevent eavesdropping, tampering, and message = forgery. TLS is
REQUIRED for = every connection between a client subscriber and server = REQUIRED for every connection between a = client subscriber and server
in this = protocol specification. Additional security measures such as = in this protocol specification. Additional = security measures such as
client = authentication during TLS negotiation MAY also be employed to = client authentication during TLS negotiation = MAY also be employed to
increase the = trust relationship between client and server. increase the trust relationship between client and = server.
=
5. State = Considerations 5. State = Considerations
=
Each DNS Push = Notification server is capable of handling some finite Each DNS Push Notification server is capable of = handling some finite
=
skipping to = change at = page 9, line 8 =C2=B6 = skipping to change at page 9, line 8 =C2=B6
employ various = techniques to limit subscriptions to a manageable employ various techniques to limit subscriptions to a = manageable
level. = Correspondingly, the client is free to establish simultaneous = level. Correspondingly, the client is free = to establish simultaneous
sessions to = alternate DNS servers that support DNS Push Notifications = sessions to alternate DNS servers that = support DNS Push Notifications
for the zone = and distribute subscriptions at the client's discretion. = for the zone and distribute subscriptions at = the client's discretion.
In this way, = both clients and servers can react to resource In this way, both clients and servers can react to = resource
= constraints. constraints.
=
6. Protocol = Operation 6. Protocol = Operation
=
The DNS Push = Notification protocol is a session-oriented protocol, The DNS Push Notification protocol is a = session-oriented protocol,
and makes = use of DNS Stateful Operations (DSO) [DSO]. and = makes use of DNS Stateful Operations (DSO) [RFC8490].
=
For details = of the DSO message format refer to the DNS Stateful For details of the DSO message format refer to the = DNS Stateful Oper-
Operations specification [DSO]. Those details are not repeated = here. = ations specification [RFC8490]. = Those details are not repeated here.
=
DNS Push = Notification clients and servers MUST support DSO. A single = DNS Push Notification clients and servers = MUST support DSO. A single
server can = support DNS Queries, DNS Updates, and DNS Push server can support DNS Queries, DNS Updates, and DNS = Push
Notifications = (using DSO) on the same TCP port. = Notifications (using DSO) on the same TCP port.
=
A DNS Push = Notification exchange begins with the client discovering = A DNS Push Notification exchange begins with = the client discovering
the = appropriate server, using the procedure described in Section = 6.1, the appropriate server, using = the procedure described in Section 6.1,
and then = making a TLS/TCP connection to it. = and then making a TLS/TCP connection to it.
=
A typical DNS = Push Notification client will immediately issue a DSO A typical DNS Push Notification client will = immediately issue a DSO
Keepalive = operation to request a session timeout or = keepalive Keepalive operation to = request a session timeout and/or = keepalive
interval = longer than the the 15-second default, but = this is not interval longer than = the the 15-second default values, but this = is
required. A = DNS Push Notification client MAY issue other requests on = not required. A DNS Push Notification = client MAY issue other
the session = first, and only issue a DSO Keepalive operation later if = requests on the session first, and only = issue a DSO Keepalive
it = determines that to be necessary. However, = Push Notification operation later = if it determines that to be necessary. Sending
subscriptions can also be used to establish the DSO session. either a DSO Keepalive = operation or a Push Notification subscription
= over the TLS/TCP = connection to the server signals the = client's
= support of DSO and = serves to establish a DSO session.
=
In accordance = with the current set of active subscriptions, the In accordance with the current set of active = subscriptions, the
server sends = relevant asynchronous Push Notifications to the client. = server sends relevant asynchronous Push = Notifications to the client.
Note that a = client MUST be prepared to receive (and silently ignore) = Note that a client MUST be prepared to = receive (and silently ignore)
Push = Notifications for subscriptions it has previously removed, = since Push Notifications for = subscriptions it has previously removed, since
there is no = way to prevent the situation where a Push Notification is = there is no way to prevent the situation = where a Push Notification is
in flight from = server to client while the client's UNSUBSCRIBE in flight from server to client while the client's = UNSUBSCRIBE
message = cancelling that subscription is simultaneously in flight from = message cancelling that subscription is = simultaneously in flight from
client to = server. client to server.
=
6.1. = Discovery 6.1. Discovery
=
The first step = in DNS Push Notification subscription is to discover The first step in DNS Push Notification subscription = is to discover
an appropriate = DNS server that supports DNS Push Notifications for an appropriate DNS server that supports DNS Push = Notifications for
the desired = zone. the desired zone.
=
The client = begins by opening a DSO Session to its normal configured = The client begins by opening a DSO Session = to its normal configured
DNS recursive = resolver and requesting a Push Notification DNS recursive resolver and requesting a Push = Notification
= subscription. This connection is made to the default DNS-over-TLS = subscription. This connection is made to TCP = port 853, the default
port as defined in DNS over TLS [RFC7858]. If this connection is port for DNS-over-TLS = DNS over TLS [RFC7858]. If the request for = a
successful, = then the recursive resolver will make appropriate Push Push Notification = subscription is successful, then the recursive
Notification = subscriptions on the client's behalf, and the client resolver will make a = corresponding Push Notification subscription on
will receive appropriate results. = the client's behalf (if the recursive resolver = doesn't already have
= an active = subscription for that name, type, and class), and pass on
= any results it = receives back to the client. This is = closely
= analogous to how = a client sends normal DNS queries to its = configured
= DNS recursive = resolver, which issues queries on the client's behalf
= (if the recursive = resolver doesn't already have appropriate answer(s)
= in its cache), and = passes on any results it receives back to the
= = client.
=
In many = contexts, the local recursive resolver = will be able to handle In many = contexts, the recursive resolver will be able to handle Push
push notifications for all zones that the client may need to = follow. = Notifications for all names that = the client may need to follow. Use
In other cases, the client may require Push Notifications from more of VPN tunnels and split-view DNS can create some = additional
than one zone, and those zones may be served by = different servers. complexity in the client software here; the techniques to handle = VPN
Therefore, it is assumed that the client may need to maintain tunnels and split-view DNS = for DNS Push Notifications are the = same as
connections to more = than one DNS Push server. = those already = used to handle this for normal DNS = queries.
=
In some cases, the recursive resolver may not be able to get = answers If the recursive resolver does not support = DNS over TLS, or does
for a particular zone. In this case, rather than = returning SERVFAIL, support DNS over TLS = but is not listening on TCP port = 853, or does
the resolver returns NOTAUTH. This signals the = client that queries support DNS over TLS on TCP port 853 but = does not support = DSO on that
for this zone can't be handled by the local caching = resolver. For port, then the DSO Session session establishment will = fail [RFC8490].
that zone, the client SHOULD contact the = zone's DNS Push server =
itself, even if all other DNS Push queries can be handled by the =
local resolver. This may be necessary in cases = where the client is
connected to a VPN, for example, or where the client has a pre-
established trust relationship with the owner of the = zone that allows
the client, but not the = local resolver, to successfully get answers
for queries in that zone.
=
If the = recursive resolver does not support Push = Notification If the recursive = resolver does support DSO but not Push = Notification
= subscriptions, then it will return an = error code, DSONOTIMPL. This = subscriptions, then it will return the DSO error code, DSOTYPENI
occurs when the local resolver follows the procedure = below and does (11).
not find an SRV record indicating support for DNS = Push Notifications.
=
In case of either = failure, the client should proceed to discover the = In some cases, the = recursive resolver may support DSO and Push
= Notification = subscriptions, but may not be able to subscribe for Push
= Notifications for a = particular name. In this case, the recursive
= resolver should = return an informative error code to the client so
= that the client can = make an informed decision how to handle the
= error. If the = recursive resolver is unable to establish a connection
= to the zone's DNS = Push Notification server (perhaps because the
= required SRV record = does not exist) the recursive resolver should
= return SERVFAIL. If = the recursive resolver is able to establish a
= connection to the = zone's DNS Push Notification server and some other
= error code is then = received, the recursive resolver should pass on
= this received error = code back to the client. In some cases, where
= the client has a = pre-established trust relationship with the owner of
= the zone (that is = not handled via the usual mechanisms for VPN
= software) the client = may handle these failures by contacting the
= zone's DNS Push = server directly.
=
= In any of the cases = described above where the client fails to
= establish a DNS Push = Notification subscription via its configured
= recursive = resolver, the client should proceed to discover the
appropriate = server for direct communication. The client MUST also appropriate server for direct communication. The = client MUST also
determine = which TCP port on the server is listening for connections, = determine which TCP port on the server is = listening for connections,
which need not = be (and often is not) the typical TCP port 53 used for which need not be (and often is not) the typical TCP = port 53 used for
conventional = DNS, or TCP port 853 used for DNS over TLS. conventional DNS, or TCP port 853 used for DNS over = TLS.
=
The discovery = algorithm described here is an iterative algorithm, The discovery algorithm described here is an = iterative algorithm,
which starts = with the full name of the record to which the client which starts with the full name of the record to = which the client
wishes to = subscribe. Successive SOA queries are then issued, wishes to subscribe. Successive SOA queries are then = issued,
trimming one = label each time, until the closest enclosing trimming one label each time, until the closest = enclosing
authoritative = server is discovered. There is also an optimization to = authoritative server is discovered. There = is also an optimization to
=
skipping to = change at = page 11, line 17 =C2=B6 = skipping to change at page 11, line = 35 =C2=B6
=
1. The client = begins the discovery by sending a DNS query to its 1. The client begins the discovery by sending a DNS = query to its
local = resolver, with record type SOA [RFC1035] for the record = local resolver, with record type SOA = [RFC1035] for the record
name to = which it wishes to subscribe. As an example, suppose the = name to which it wishes to subscribe. = As an example, suppose the
client = wishes to subscribe to PTR records with the name client wishes to subscribe to PTR records with = the name
= _ipp._tcp.foo.example.com (to discover Internet Printing = Protocol = _ipp._tcp.foo.example.com (to discover Internet Printing = Protocol
(IPP) = printers [RFC8010] [RFC8011] being advertised at (IPP) printers [RFC8010] [RFC8011] being = advertised at
= "foo.example.com"). The client begins by sending an SOA query = "foo.example.com"). The client begins = by sending an SOA query
for = _ipp._tcp.foo.example.com to the local recursive resolver. = for _ipp._tcp.foo.example.com to the = local recursive resolver.
The goal = is to determine the server authoritative for the name The goal is to determine the server authoritative = for the name
= _ipp._tcp.foo.example.com. The DNS zone containing the name = _ipp._tcp.foo.example.com. The closest enclosing DNS zone
= _ipp._tcp.foo.example.com could be example.com, or containing the name _ipp._tcp.foo.example.com = could be
= foo.example.com, or _tcp.foo.example.com, or even example.com, or foo.example.com, or = _tcp.foo.example.com, or even
= _ipp._tcp.foo.example.com. The client does not know in advance = _ipp._tcp.foo.example.com. The client = does not know in advance
where the = closest enclosing zone cut occurs, which is why it uses = where the closest enclosing zone cut = occurs, which is why it uses
the = procedure described here to discover this information. the iterative = procedure described here to discover this
= information.
=
2. If the = requested SOA record exists, it will be returned in the = 2. If the requested SOA record exists, it = will be returned in the
Answer = section with a NOERROR response code, and the client has = Answer section with a NOERROR response = code, and the client has
= succeeded in discovering the information it needs. (This text is = succeeded in discovering the information it needs.
not = placing any new requirements on DNS recursive resolvers. It = (This language is not placing any new = requirements on DNS
is merely describing the existing operation of the DNS = protocol recursive resolvers. = This text merely describes the existing
= [RFC1034] [RFC1035].) = operation of the DNS protocol [RFC1034] [RFC1035].)
=
3. If the = requested SOA record does not exist, the client will get = 3. If the requested SOA record does not = exist, the client will get
back a = NOERROR/NODATA response or an NXDOMAIN/Name Error back a NOERROR/NODATA response or an = NXDOMAIN/Name Error
response. = In either case, the local resolver would normally response. In either case, the local resolver = would normally
include = the SOA record for the zone of the requested name in the = include the SOA record for the closest enclosing zone of the
= Authority Section. If the SOA record is received in the = requested name in the Authority = Section. If the SOA record is
= Authority Section, then the client has succeeded in discovering = received in the Authority Section, then = the client has succeeded
the = information it needs. (This text is not = placing any new in discovering = the information it needs.
= requirements on DNS recursive resolvers. It = is merely describing = (This language is not placing any new requirements on = DNS
the = existing operation of the DNS protocol regarding negative = recursive resolvers. This text merely describes the existing
= responses [RFC2308].) = operation of the DNS protocol regarding negative responses
= [RFC2308].)
=
4. If the = client receives a response containing no SOA record, then = 4. If the client receives a response = containing no SOA record, then
it = proceeds with the iterative approach. The client strips the = it proceeds with the iterative approach. = The client strips the
leading = label from the current query name and if the resulting leading label from the current query name and if = the resulting
name has = at least one label in it, the client sends a = new SOA name has at = least one label in it, the client sends an = SOA query
query, and processing continues at step 2 above, = repeating the = for that new name, and processing continues at step 2 = above,
= iterative search until either an SOA is received, or the query = repeating the iterative search until = either an SOA is received,
name = is empty. In the case of an empty name, this is a network = or the query name consists of a single label, i.e., a Top = Level
= configuration error which should not happen and the client = gives = Domain (TLD). In the case of a = single-label TLD, this is a
up. The = client may retry the operation at a later time, of the network configuration error which should not = happen and the
client's = choosing, such after a change in network attachment. client gives up. The client may retry the = operation at a later
= time, of the client's choosing, such = after a change in network
= attachment.
=
5. Once the = SOA is known (either by virtue of being seen in the 5. Once the SOA is known (either by virtue of being = seen in the
Answer = Section, or in the Authority Section), the client sends a = Answer Section, or in the Authority = Section), the client sends a
DNS query = with type SRV [RFC2782] for the record name DNS query with type SRV [RFC2782] for the record = name
= "_dns-push-tls._tcp.<zone>", where <zone> is the owner name = of = "_dns-push-tls._tcp.<zone>", where <zone> is the owner name = of
the = discovered SOA record. the = discovered SOA record.
=
6. If the = zone in question is set up to offer DNS Push Notifications = 6. If the zone in question is set up to = offer DNS Push Notifications
then this = SRV record MUST exist. (If this SRV record does not then this SRV record MUST exist. (If this SRV = record does not
exist then = the zone is not correctly configured for DNS Push exist then the zone is not correctly configured = for DNS Push
=
skipping to = change at = page 13, line 8 =C2=B6 = skipping to change at page 14, line 8 =C2=B6
the client = device MUST respect the DNS TTL values on records it the client device MUST respect the DNS TTL values on = records it
receives, and = store them in its local cache with this lifetime. This = receives, and store them in its local cache = with this lifetime. This
means that, as = long as the DNS TTL values on the authoritative means that, as long as the DNS TTL values on the = authoritative
records were = set to reasonable values, repeated application of this records were set to reasonable values, repeated = application of this
discovery = process can be completed nearly instantaneously by the discovery process can be completed nearly = instantaneously by the
client, using = only locally-stored cached data. = client, using only locally-stored cached data.
=
6.2. DNS Push = Notification SUBSCRIBE 6.2. DNS Push = Notification SUBSCRIBE
=
After = connecting, and requesting a longer idle timeout and/or = After connecting, and requesting a longer = idle timeout and/or
keepalive = interval if necessary, a DNS Push Notification client then = keepalive interval if necessary, a DNS Push = Notification client
indicates = its desire to receive DNS Push Notifications for a given = then indicates its desire to receive DNS = Push Notifications for
domain name = by sending a SUBSCRIBE request over the = established DSO a given = domain name by sending a SUBSCRIBE request to the server.
session to the server. A SUBSCRIBE request = is encoded in a DSO [DSO] = A SUBSCRIBE request is encoded in a DSO = message [RFC8490].
message. This specification defines a = primary DSO TLV for DNS Push This = specification defines a primary DSO TLV for DNS Push
Notification = SUBSCRIBE Requests (tentatively DSO Type Code 0x40). Notification SUBSCRIBE Requests (tentatively DSO Type = Code 0x40).
=
The entity = that initiates a SUBSCRIBE request is by definition the = The entity that initiates a SUBSCRIBE = request is by definition the
client. A = server MUST NOT send a SUBSCRIBE request over an existing = client. A server MUST NOT send a SUBSCRIBE = request over an existing
session from a = client. If a server does send a SUBSCRIBE request session from a client. If a server does send a = SUBSCRIBE request
over a DSO = session initiated by a client, this is a fatal error and = over a DSO session initiated by a client, = this is a fatal error and
the client = should immediately abort the connection with a TCP RST (or = the client should immediately abort the = connection with a TCP RST (or
equivalent for = other protocols). equivalent for = other protocols).
=
6.2.1. SUBSCRIBE = Request 6.2.1. SUBSCRIBE = Request
=
A SUBSCRIBE = request begins with the standard DSO 12-byte header A SUBSCRIBE request begins with the standard DSO = 12-byte header
[DSO], followed by the SUBSCRIBE TLV. A = SUBSCRIBE request message is [RFC8490], followed by the SUBSCRIBE primary TLV. A SUBSCRIBE
illustrated = in Figure 1. request message is = illustrated in Figure 1.
=
The MESSAGE ID = field MUST be set to a unique value, that the client The MESSAGE ID field MUST be set to a unique value, = that the client
is not using = for any other active operation on this session. For the = is not using for any other active operation = on this DSO session. For
purposes = here, a MESSAGE ID is in use on this session if the client = the purposes here, a MESSAGE ID is in use = on this session if the
has used it = in a request for which it has not yet received a client has used it in a request for which it has not = yet received a
response, or = if the client has used it for a subscription which it response, or if the client has used it for a = subscription which it
has not yet = cancelled using UNSUBSCRIBE. In the SUBSCRIBE response = has not yet cancelled using UNSUBSCRIBE. In = the SUBSCRIBE response
the server = MUST echo back the MESSAGE ID value unchanged. the server MUST echo back the MESSAGE ID value = unchanged.
=
The other = header fields MUST be set as described in the DSO The other header fields MUST be set as described in = the DSO spec-
specification [DSO]. The DNS Opcode is the DSO = Opcode. The four ification [RFC8490]. The DNS OPCODE field contains the OPCODE value
count fields = MUST be zero, and the corresponding four sections MUST for DNS Stateful Operations = (6). The four count fields MUST be zero,
be empty = (i.e., absent). and the = corresponding four sections MUST be empty (i.e., absent).
=
The DSO-TYPE = is SUBSCRIBE. The DSO-LENGTH is the = length of the DSO- The DSO-TYPE is SUBSCRIBE = (tentatively 0x40).
DATA that follows, which specifies the name, = type, and class of the =
record(s) = being sought. The DSO-LENGTH is = the length of the DSO-DATA that follows, = which
= specifies the name, type, and class of the = record(s) being sought.
=
= 1 1 1 1 1 1 = 1 1 1 1 1 1
0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = MESSAGE ID | \ | MESSAGE ID | = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
|QR| Opcode | Z | RCODE | = | |QR| OPCODE(6) | Z | RCODE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER
| = ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
| DSO-TYPE =3D SUBSCRIBE = | | DSO-TYPE =3D SUBSCRIBE (tentatively 0x40) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| = DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = | \ | | = \
\ = NAME \ | \ NAME \ = |
\ = \ | \ \ = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = DSO-DATA = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = DSO-DATA
| = TYPE | | | TYPE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = CLASS | / | CLASS | = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
=
= Figure 1: SUBSCRIBE Request = Figure 1: SUBSCRIBE Request
=
The DSO-DATA = for a SUBSCRIBE request MUST contain exactly one NAME, The DSO-DATA for a SUBSCRIBE request MUST contain = exactly one NAME,
Type, and CLASS. Since SUBSCRIBE requests are = sent over TCP, TYPE, and CLASS. Since SUBSCRIBE requests are = sent over TCP,
multiple = SUBSCRIBE request messages can be concatenated in a single = multiple SUBSCRIBE DSO request messages can be concatenated in = a
TCP stream = and packed efficiently into TCP segments. single TCP stream and packed efficiently into TCP = segments.
=
If accepted, = the subscription will stay in effect until the client If accepted, the subscription will stay in effect = until the client
cancels the = subscription using UNSUBSCRIBE or until the DSO session = cancels the subscription using UNSUBSCRIBE = or until the DSO session
between the = client and the server is closed. = between the client and the server is closed.
=
SUBSCRIBE = requests on a given session MUST be unique. A client MUST = SUBSCRIBE requests on a given session MUST = be unique. A client MUST
NOT send a = SUBSCRIBE message that duplicates the NAME, TYPE and CLASS = NOT send a SUBSCRIBE message that duplicates = the NAME, TYPE and CLASS
of an existing = active subscription on that DSO session. For the of an existing active subscription on that DSO = session. For the
purpose of = this matching, the established DNS case-insensitivity for = purpose of this matching, the established = DNS case-insensitivity for
US-ASCII = letters applies (e.g., "example.com" and "Example.com" are = US-ASCII letters applies (e.g., = "example.com" and "Example.com" are
=
skipping to = change at = page 15, line 15 =C2=B6 = skipping to change at page 16, line = 15 =C2=B6
DNS = wildcarding is not supported. That is, a wildcard ("*") in a = DNS wildcarding is not supported. That is, = a wildcard ("*") in a
SUBSCRIBE = message matches only a literal wildcard character ("*") in = SUBSCRIBE message matches only a literal = wildcard character ("*") in
the zone, and = nothing else. the zone, and nothing = else.
=
Aliasing is = not supported. That is, a CNAME in a SUBSCRIBE message = Aliasing is not supported. That is, a CNAME = in a SUBSCRIBE message
matches only a = literal CNAME record in the zone, and nothing else. matches only a literal CNAME record in the zone, and = nothing else.
=
A client may = SUBSCRIBE to records that are unknown to the server at A client may SUBSCRIBE to records that are unknown to = the server at
the time of = the request (providing that the name falls within one of = the time of the request (providing that the = name falls within one of
the zone(s) = the server is responsible for) and this is not an error. = the zone(s) the server is responsible for) = and this is not an error.
The server = MUST accept these requests and send Push Notifications if = The server MUST NOT = return NXDOMAIN in this case. The server MUST
and when = matching records are found in the future. accept these requests and send Push Notifications if = and when
= matching records are found in the = future.
=
If neither = TYPE nor CLASS are ANY (255) then this is a specific If neither TYPE nor CLASS are ANY (255) then this is = a specific
subscription = to changes for the given NAME, TYPE and CLASS. If one subscription to changes for the given NAME, TYPE and = CLASS. If one
or both of = TYPE or CLASS are ANY (255) then this subscription matches = or both of TYPE or CLASS are ANY (255) then = this subscription matches
any type = and/or any class, as appropriate. = any type and/or any class, as appropriate.
=
NOTE: A = little-known quirk of DNS is that in DNS QUERY requests, = NOTE: A little-known quirk of DNS is that in = DNS QUERY requests,
QTYPE and = QCLASS 255 mean "ANY" not "ALL". They indicate that the = QTYPE and QCLASS 255 mean "ANY" not "ALL". = They indicate that the
server should = respond with ANY matching records of its choosing, not server should respond with ANY matching records of = its choosing, not
necessarily = ALL matching records. This can lead to some surprising = necessarily ALL matching records. This can = lead to some surprising
=
skipping to = change at = page 16, line 10 =C2=B6 = skipping to change at page 17, line = 10 =C2=B6
interpreted to = mean "ALL", not "ANY". After accepting a subscription interpreted to mean "ALL", not "ANY". After = accepting a subscription
where one or = both of TYPE or CLASS are 255, the server MUST send Push = where one or both of TYPE or CLASS are 255, = the server MUST send Push
Notification = Updates for ALL record changes that match the Notification Updates for ALL record changes that = match the
subscription, = not just some of them. = subscription, not just some of them.
=
6.2.2. SUBSCRIBE = Response 6.2.2. SUBSCRIBE = Response
=
Each SUBSCRIBE = request generates exactly one SUBSCRIBE response from Each SUBSCRIBE request generates exactly one = SUBSCRIBE response from
the = server. the server.
=
A SUBSCRIBE = response message begins with the standard = DSO 12-byte A SUBSCRIBE response = begins with the standard DSO 12-byte header
header [DSO], possibly followed by one or more optional = TLVs, such as [RFC8490], possibly followed by one or more = optional TLVs, such as a
a Retry = Delay TLV. Retry Delay = TLV.
=
The MESSAGE ID = field MUST echo the value given in the ID field of the The MESSAGE ID field MUST echo the value given in the = ID field of the
SUBSCRIBE = request. This is how the client knows which request is = SUBSCRIBE request. This is how the client = knows which request is
being = responded to. being responded = to.
=
A SUBSCRIBE = response message MUST NOT include a SUBSCRIBE TLV. If a = A SUBSCRIBE response message MUST NOT = include a SUBSCRIBE TLV. If a
client = receives a SUBSCRIBE response message containing a SUBSCRIBE = client receives a SUBSCRIBE response message = containing a SUBSCRIBE
TLV then the = response message is processed but the SUBSCRIBE TLV MUST = TLV then the response message is processed = but the SUBSCRIBE TLV MUST
be silently = ignored. be silently = ignored.
=
=
skipping = to change at page 17, line = 6 =C2=B6 = skipping to change at page 18, line = 6 =C2=B6
=
This document = specifies only these RCODE values for SUBSCRIBE This document specifies only these RCODE values for = SUBSCRIBE
Responses. = Servers sending SUBSCRIBE Responses SHOULD use one of Responses. Servers sending SUBSCRIBE Responses = SHOULD use one of
these values. = Note that NXDOMAIN is not a valid RCODE in response to these values. Note that NXDOMAIN is not a valid = RCODE in response to
a SUBSCRIBE = Request. However, future circumstances may create a SUBSCRIBE Request. However, future circumstances = may create
situations = where other RCODE values are appropriate in SUBSCRIBE situations where other RCODE values are appropriate = in SUBSCRIBE
Responses, so = clients MUST be prepared to accept SUBSCRIBE Responses Responses, so clients MUST be prepared to accept = SUBSCRIBE Responses
with any other = RCODE value. with any other RCODE = value.
=
If the server = sends a nonzero RCODE in the SUBSCRIBE response, that If the server sends a nonzero RCODE in the SUBSCRIBE = response, that
= means means:
=
a. the client = is (at least partially) misconfigured, = a. the client is (at least partially) misconfigured,
b. the server = resources are exhausted, or b. the = server resources are exhausted, or
c. there is = some other unknown failure on the server. c. there is some other unknown failure on the = server.
=
In any case, = the client shouldn't retry the subscription to this In any case, the client shouldn't retry the = subscription to this
server right = away. If multiple SRV records were returned as server right away. If multiple SRV records were = returned as
described in = discovery Section 6.1, Paragraph 7, a = subsequent server described in = Section 6.1, Paragraph 7, a subsequent server can be
can be tried = immediately. tried = immediately.
=
If the client = has other successful subscriptions to this server, If the client has other successful subscriptions to = this server,
these = subscriptions can remain even though = additional subscriptions these = subscriptions remain even though additional subscriptions may
may be = refused. Neither the client, nor the = server are required to be refused. = Neither the client nor the server are = required to close
close the = connection, although, either end may choose to do so. the connection, although, either end may choose to = do so.
=
If the server = sends a nonzero RCODE then it SHOULD append a Retry If the server sends a nonzero RCODE then it SHOULD = append a Retry
Delay TLV = [DSO] to the response specifying a delay = before the client Delay TLV [RFC8490] to the response specifying a delay = before the
attempts = this operation again. Recommended values for the delay for = client attempts this operation again. = Recommended values for the
different = RCODE values are given below. These recommended values = delay for different RCODE values are given = below. These recommended
apply both = to the default values a server should place in the Retry = values apply both to the default values a = server should place in the
Delay TLV, = and the default values a client should assume if the Retry Delay TLV, and the default values a client = should assume if the
server = provides no Retry Delay TLV. server = provides no Retry Delay TLV.
=
For RCODE =3D= 1 (FORMERR) the delay may be any value selected by the = For RCODE =3D 1 (FORMERR) the delay may = be any value selected by the
= implementer. A value of five minutes is RECOMMENDED, to reduce = implementer. A value of five minutes is = RECOMMENDED, to reduce
the risk of = high load from defective clients. = the risk of high load from defective clients.
=
For RCODE =3D= 2 (SERVFAIL) the delay should be chosen according to For RCODE =3D 2 (SERVFAIL) the delay should be = chosen according to
the level = of server overload and the anticipated duration of that = the level of server overload and the = anticipated duration of that
overload. = By default, a value of one minute is RECOMMENDED. If a = overload. By default, a value of one = minute is RECOMMENDED. If a
more = serious server failure occurs, the delay may be longer in = more serious server failure occurs, the = delay may be longer in
accordance = with the specific problem encountered. = accordance with the specific problem encountered.
=
For RCODE =3D= 4 (NOTIMP), which occurs on a server that doesn't For RCODE =3D 4 (NOTIMP), which occurs on a server = that doesn't
implement = DSO [DSO], it is unlikely that the server = will begin implement DNS Stateful Operations [RFC8490], it is = unlikely that
= supporting DSO in the next few minutes, so the retry delay = SHOULD the server will begin = supporting DSO in the next few minutes, so
be one = hour. Note that in such a case, a server that doesn't the retry delay SHOULD be one hour. Note that in = such a case, a
implement = DSO is unlikely to place a Retry Delay TLV in its server that doesn't implement DSO is unlikely to = place a Retry
response, = so this recommended value in particular applies to what = Delay TLV in its response, so this = recommended value in particular
a client = should assume by default. = applies to what a client should assume by default.
=
For RCODE =3D= 5 (REFUSED), which occurs on a server that implements For RCODE =3D 5 (REFUSED), which occurs on a = server that implements
DNS Push = Notifications, but is currently configured to disallow DNS Push Notifications, but is currently = configured to disallow
DNS Push = Notifications, the retry delay may be any value selected = DNS Push Notifications, the retry delay = may be any value selected
by the = implementer and/or configured by the operator. by the implementer and/or configured by the = operator.
=
If the = server being queried is not the local resolver, this is a If the server being queried is listed in a
= misconfiguration, since this server is listed in = a = "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is
"_dns-push-tls._tcp.<zone>" SRV = record, but the server itself is a misconfiguration, since this server is being advertised as
not = currently configured to support DNS Push = Notifications for supporting DNS Push Notifications for this = zone, but the server
that = zone. Since it is possible that the = misconfiguration may be itself = is not currently configured to perform = that task. Since it
repaired = at any time, the retry delay should not be set too high. = is possible that the misconfiguration = may be repaired at any time,
By = default, a value of 5 minutes is RECOMMENDED. the retry delay should not be set too high. By = default, a value
= of 5 minutes is RECOMMENDED.
=
For RCODE =3D= 9 (NOTAUTH), which occurs on a server that implements For RCODE =3D 9 (NOTAUTH), which occurs on a = server that implements
DNS Push = Notifications, but is not configured to be authoritative = DNS Push Notifications, but is not = configured to be authoritative
for the = requested name, the retry delay may be any value selected = for the requested name, the retry delay = may be any value selected
by the = implementer and/or configured by the operator. by the implementer and/or configured by the = operator.
=
This is a misconfiguration, since this server is = listed in a If the server being = queried is listed in a
= "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is = "_dns-push-tls._tcp.<zone>" SRV = record for the zone, then this is
not = currently configured to support DNS Push = Notifications for a misconfiguration, since this server is being = advertised as
that = zone. Since it is possible that the = misconfiguration may be supporting DNS Push Notifications for this = zone, but the server
repaired = at any time, the retry delay should not be set too high. = itself is not currently configured to = perform that task. Since it
By = default, a value of 5 minutes is RECOMMENDED. is possible that the misconfiguration may be = repaired at any time,
= the retry delay should not be set too = high. By default, a value
= of 5 minutes is RECOMMENDED.
=
For RCODE = =3D 11 (DSOTYPENI), which occurs on a server that doesn't = For RCODE =3D 11 (DSOTYPENI), which = occurs on a server that
implement = DNS Push Notifications, it is unlikely that the server implements DSO but = doesn't implement DNS Push Notifications, it is
will = begin supporting DNS Push Notifications in the next few = unlikely that the server will begin = supporting DNS Push
minutes, = so the retry delay SHOULD be one hour. = Notifications in the next few minutes, so the retry delay = SHOULD
= be one hour.
=
For other = RCODE values, the retry delay should be set by the For other RCODE values, the retry delay should be = set by the
server as = appropriate for that error condition. By default, a server as appropriate for that error condition. = By default, a
value of 5 = minutes is RECOMMENDED. value of = 5 minutes is RECOMMENDED.
=
For RCODE =3D = 9 (NOTAUTH), the time delay applies to requests for other = For RCODE =3D 9 (NOTAUTH), the time delay = applies to requests for other
names falling = within the same zone. Requests for names falling names falling within the same zone. Requests for = names falling
within other = zones are not subject to the delay. For all other within other zones are not subject to the delay. For = all other
RCODEs the = time delay applies to all subsequent requests to this RCODEs the time delay applies to all subsequent = requests to this
= server. server.
=
After sending = an error response the server MAY allow the session to After sending an error response the server MAY allow = the session to
remain open, = or MAY send a DNS Push Notification Retry Delay remain open, or MAY send a DNS Push Notification = Retry Delay
Operation TLV = instructing the client to close the session, as Operation TLV instructing the client to close the = session, as
described in = the DSO specification [DSO]. Clients MUST = correctly described in the DSO = specification [RFC8490]. Clients MUST = correctly
handle both = cases. handle both cases.
=
6.3. DNS Push = Notification Updates 6.3. DNS Push = Notification Updates
=
Once a = subscription has been successfully established, the server = Once a subscription has been successfully = established, the server
generates PUSH = messages to send to the client as appropriate. In the generates PUSH messages to send to the client as = appropriate. In the
case that = the answer set was non-empty at the moment the subscription = case that the answer set was already non-empty at the moment the
was = established, an initial PUSH message will be sent immediately = subscription was established, an initial = PUSH message will be sent
following = the SUBSCRIBE Response. Subsequent changes to the answer = immediately following the SUBSCRIBE = Response. Subsequent changes to
set are then = communicated to the client in subsequent PUSH messages. = the answer set are then communicated to the = client in subsequent PUSH
= messages.
=
6.3.1. PUSH = Message 6.3.1. PUSH Message
=
A PUSH = message begins with the standard DSO 12-byte header [DSO], A = PUSH unidirectional message begins with = the standard DSO 12-byte
followed by = the PUSH TLV. A PUSH message is illustrated in Figure 2. = header [RFC8490], followed by the PUSH primary TLV. A PUSH message
= is illustrated in Figure 2.
=
In accordance = with the definition of DSO unidirectional messages, the = In accordance with the definition of DSO = unidirectional messages, the
MESSAGE ID = field MUST be zero. There is no client response to a PUSH = MESSAGE ID field MUST be zero. There is no = client response to a PUSH
= message. message.
=
The other = header fields MUST also be set as = described in the DSO The other = header fields MUST be set as described in the DSO spec-
specification [DSO]. The DNS Opcode is the DSO = Opcode. The four ification [RFC8490]. The DNS OPCODE field contains the OPCODE value
count fields = MUST be zero, and the corresponding four sections MUST for DNS Stateful Operations = (6). The four count fields MUST be zero,
be empty = (i.e., absent). and the = corresponding four sections MUST be empty (i.e., absent).
=
The DSO-TYPE = is PUSH (tentatively 0x41). The DSO-LENGTH is = the The DSO-TYPE is PUSH = (tentatively 0x41).
length of the DSO-DATA that follows, which specifies = the changes
being communicated.
=
The DSO-DATA contains one or more Update records. A PUSH = Message The DSO-LENGTH is the length = of the DSO-DATA that follows, = which
MUST contain at least one Update record. If a PUSH = Message is specifies the changes = being communicated.
received that contains zero Update records, = this is a fatal error, =
and the receiver MUST = immediately terminate the connection with = a TCP
RST (or equivalent for other protocols). The Update = records are
formatted in the customary way for Resource Records = in DNS messages.
Update records in a PUSH Message are interpreted = according to the
same rules as for DNS Update [RFC2136] messages, = namely:
=
Delete all RRsets from a name: = The DSO-DATA contains one or more change = notifications. A PUSH
TTL=3D0, CLASS=3DANY, RDLENGTH=3D0, = TYPE=3DANY. Message MUST contain at least one change = notification. If a PUSH
= Message is received = that contains no change notifications, this is a
= fatal error, and the = receiver MUST immediately terminate the
= connection with a = TCP RST (or equivalent for other protocols).
=
Delete an RRset from a name: = The change notification records are formatted = similarly to how DNS
TTL=3D0, CLASS=3DANY, RDLENGTH=3D0;= Resource Records = are conventionally expressed in DNS messages, as
TYPE = specifies the RRset being deleted. illustrated in Figure 2, and are interpreted as = described below.
=
= The TTL field = holds an unsigned 32-bit integer = [RFC2181]. If the TTL
= is in the range 0 to = 2,147,483,647 seconds (2^31 - 1, or 0x7FFFFFFF),
= then a new DNS = Resource Record with the given name, type, class and
= RDATA is added. A = TTL of 0 means that this record should be retained
= for as long as the = subscription is active, and should be discarded
= immediately the = moment the subscription is cancelled.
=
= If the TTL has the = value 0xFFFFFFFF, then the DNS Resource Record
= with the given name, = type, class and RDATA is removed.
=
= If the TTL has the = value 0xFFFFFFFE, then this is a 'collective'
= remove notification. = For collective remove notifications RDLEN MUST
= be zero and = consequently the RDATA MUST be empty. If a change
= notification is = received where TTL =3D 0xFFFFFFFE and RDLEN is not
= zero, this is a = fatal error, and the receiver MUST immediately
= terminate the = connection with a TCP RST (or equivalent for other
= protocols). There = are three types of collective remove notification:
=
= For collective = remove notifications, if CLASS is 255 (ANY), then for
= the given name this = deletes all records of all types in all classes.
= In this case TYPE = MUST be set to zero on transmission, and MUST be
= silently ignored on = reception.
=
= For collective = remove notifications, if CLASS is not 255 (ANY) and
= TYPE is 255 (ANY) = then for the given name this deletes all records of
= all types in the = specified class.
=
= For collective = remove notifications, if CLASS is not 255 (ANY) and
= TYPE is not 255 = (ANY) then for the given name this deletes all
= records of the = specified type in the specified class.
=
= Summary of change = notification types:
=
= Delete all RRsets = from a name, in all classes
= TTL=3D0xFFFFFFFE, = RDLENGTH=3D0, CLASS=3D255 (ANY)
=
= Delete all RRsets = from a name, in given class:
= TTL=3D0xFFFFFFFE, = RDLENGTH=3D0, CLASS specifies class, TYPE=3D255 (ANY)
=
= Delete = specified RRset from a name, in given = class:
= TTL=3D0xFFFFFFFE, = RDLENGTH=3D0
= CLASS and = TYPE specify the RRset being deleted
=
Delete an = individual RR from a name: = Delete an individual RR from a name:
TTL=3D0, CLASS=3DNONE; TTL=3D0xFFFFFFFF
TYPE, = RDLENGTH and RDATA specifies the RR being = deleted. = CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted.
=
Add to = an RRset: Add individual RR = to a name
= = TTL>=3D0
= CLASS, TYPE, = RDLENGTH, RDATA and TTL specify the RR being added.
=
TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being = added. Note that it is valid for the RDATA of an added or = removed DNS
= Resource Record to = be empty (zero length). For example, an Address
= Prefix List Resource = Record [RFC3123] may have empty RDATA.
= Therefore, a change = notification with RDLEN=3D0 does not automatically
= indicate a remove = notification. If RDLEN=3D0 and TTL is the in the
= range 0 - = 0x7FFFFFFF, this change notification signals the addition
= of a record with the = given name, type, class, and empty RDATA. If
= RDLEN=3D0 and = TTL =3D 0xFFFFFFFF, this change notification = signals the
= removal specifically = of that single record with the given name, type,
= class, and empty = RDATA.
=
= If the TTL is any = value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value
= in the range 0 - = 0x7FFFFFFF, then the receiver SHOULD silently ignore
= this particular = change notification record. The connection is not
= terminated and other = valid change notification records within this
= PUSH message are = processed as usual.
=
= For efficiency, when = generating a PUSH message, a server SHOULD
= include as many = change notifications as it has immediately available
= to send, rather than = sending each change notification as a separate
= DSO message. Once = it has exhausted the list of change notifications
= immediately = available to send, a server SHOULD then send the PUSH
= message immediately, = rather than waiting to see if additional change
= notifications become = available.
=
= For efficiency, when = generating a PUSH message, a server SHOULD use
= standard DNS name = compression, with offsets relative to the beginning
= of the DNS message = [RFC1035]. When multiple change notifications in
= a single PUSH = message have the same owner name, this name compression
= can yield = significant savings. Name compression should be = performed
= as specified in = Section 18.14 of the Multicast DNS specification
= [RFC6762], namely, = owner names should always be compressed, and names
= appearing = within RDATA should be compressed for = only the RR types
= listed = below:
=
= NS, CNAME, PTR, = DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
=
= Servers may generate = PUSH messages up to a maximum DNS message length
= of 16,382 bytes, = counting from the start of the DSO 12-byte header.
= Including the = two-byte length prefix that is used to frame DNS over a
= byte stream like = TLS, this makes a total of 16,384 bytes. Servers
= MUST NOT generate = PUSH messages larger than this. Where the
= immediately = available change notifications are sufficient to exceed a
= DNS message length = of 16,382 bytes, the change notifications MUST be
= communicated in = separate PUSH messages of up to 16,382 bytes each.
= DNS name compression = becomes less effective for messages larger than
= 16,384 bytes, so = little efficiency benefit is gained by sending
= messages larger than = this.
=
= If a client receives = a PUSH message with a DNS message length larger
= than 16,382 bytes, = the this is a fatal error, and the receiver MUST
= immediately = terminate the connection with a TCP RST (or equivalent
= for other = protocols).
=
= 1 1 1 1 1 1 = 1 1 1 1 1 1
0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = MESSAGE ID (MUST BE ZERO) | \ | MESSAGE ID (MUST BE ZERO) | = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
|QR| Opcode | Z | RCODE | = | |QR| OPCODE(6) | Z | RCODE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER
| = ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
| = DSO-TYPE =3D PUSH = | | DSO-TYPE =3D PUSH (tentatively 0x41) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| = DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
\ = NAME \ \ \ NAME \ = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = TYPE | | | TYPE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = CLASS | | | CLASS | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = TTL | | | TTL | = |
| = (32 bits) = | > DSO-DATA | (32-bit unsigned big-endian integer) | = > DSO-DATA
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = RDLEN | | | RDLEN | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
\ = RDATA \ = | \ RDATA (sized as necessary) \ = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
: NAME, = TYPE, CLASS, TTL, RDLEN, RDATA : | : NAME, TYPE, CLASS, TTL, RDLEN, RDATA : = |
: = Repeated As Necessary : / : Repeated As Necessary : = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
=
= Figure 2: PUSH Message = Figure 2: PUSH Message
=
When = processing the records received in a PUSH Message, the = receiving When processing the = records received in a PUSH Message, the receiving
client MUST = validate that the records being added or deleted client MUST validate that the records being added or = deleted
correspond = with at least one currently active subscription on that = correspond with at least one currently = active subscription on that
session. = Specifically, the record name MUST match the name given in = session. Specifically, the record name MUST = match the name given in
the SUBSCRIBE request, subject to the usual = established DNS case- a SUBSCRIBE request, subject to the usual = established DNS case-
insensitivity = for US-ASCII letters. If the TYPE in the SUBSCRIBE insensitivity for US-ASCII letters. If the TYPE in = the SUBSCRIBE
request was = not ANY (255) then the TYPE of the record must match the = request was not ANY (255) then the TYPE of = the record must match the
TYPE given in = the SUBSCRIBE request. If the CLASS in the SUBSCRIBE TYPE given in the SUBSCRIBE request. If the CLASS in = the SUBSCRIBE
request was = not ANY (255) then the CLASS of the record must match the = request was not ANY (255) then the CLASS of = the record must match the
CLASS given in = the SUBSCRIBE request. If a matching active CLASS given in the SUBSCRIBE request. If a matching = active
subscription = on that session is not found, then that individual subscription on that session is not found, then that = individual
record = addition/deletion is silently ignored. Processing of other = record addition/deletion is silently = ignored. Processing of other
additions and = deletions in this message is not affected. The DSO additions and deletions in this message is not = affected. The DSO
session is not = closed. This is to allow for the unavoidable race session is not closed. This is to allow for the = unavoidable race
condition = where a client sends an outbound UNSUBSCRIBE while inbound = condition where a client sends an outbound = UNSUBSCRIBE while inbound
PUSH messages = for that subscription from the server are still in PUSH messages for that subscription from the server = are still in
= flight. flight.
=
In the case = where a single change affects more than one active In the case where a single change affects more than = one active
subscription, = only one PUSH message is sent. For example, a PUSH subscription, only one PUSH message is sent. For = example, a PUSH
message adding = a given record may match both a SUBSCRIBE request with message adding a given record may match both a = SUBSCRIBE request with
the same = TYPE and a different SUBSCRIBE request with TYPE=3DANY. It is the same TYPE and a different SUBSCRIBE request with = TYPE=3DANY (255).
not the case = that two PUSH messages are sent because the new record It is not the case that two PUSH messages are sent = because the new
matches two = active subscriptions. record = matches two active subscriptions.
=
The server = SHOULD encode change notifications in the most efficient = The server SHOULD encode change = notifications in the most efficient
manner = possible. For example, when three AAAA records are deleted = manner possible. For example, when three = AAAA records are deleted
from a given = name, and no other AAAA records exist for that name, the = from a given name, and no other AAAA records = exist for that name, the
server SHOULD = send a "delete an RRset from a name" PUSH message, not server SHOULD send a "delete an RRset from a name" = PUSH message, not
three separate = "delete an individual RR from a name" PUSH messages. three separate "delete an individual RR from a name" = PUSH messages.
Similarly, = when both an SRV and a TXT record are deleted from a given = Similarly, when both an SRV and a TXT record = are deleted from a given
name, and no = other records of any kind exist for that name, the name, and no other records of any kind exist for that = name, the
server SHOULD = send a "delete all RRsets from a name" PUSH message, server SHOULD send a "delete all RRsets from a name" = PUSH message,
not two = separate "delete an RRset from a name" PUSH messages. not two separate "delete an RRset from a name" PUSH = messages.
=
skipping = to change at page 22, line = 10 =C2=B6 = skipping to change at page 25, line = 10 =C2=B6
record is = still there. Once a subscription is cancelled record is still there. Once a subscription is = cancelled
(individually, = or as a result of the DSO session being closed) record (individually, or as a result of the DSO session = being closed) record
aging for = records covered by the subscription resumes and records are = aging for records covered by the = subscription resumes and records are
removed from = the local cache when their TTL reaches zero. removed from the local cache when their TTL reaches = zero.
=
6.4. DNS Push = Notification UNSUBSCRIBE 6.4. DNS = Push Notification UNSUBSCRIBE
=
To cancel an = individual subscription without closing the entire DSO To cancel an individual subscription without closing = the entire DSO
session, the = client sends an UNSUBSCRIBE message over the established = session, the client sends an UNSUBSCRIBE = message over the established
DSO session to = the server. The UNSUBSCRIBE message is encoded as a DSO session to the server. The UNSUBSCRIBE message = is encoded as a
DSO [DSO] unidirectional message. This = specification defines a DSO unidirectional message [RFC8490]. This = specification defines a
primary = unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE = primary unidirectional DSO TLV for DNS Push = Notification UNSUBSCRIBE
Requests (tentatively DSO Type Code = 0x42). Messages (tentatively DSO Type Code = 0x42).
=
A server = MUST NOT initiate an UNSUBSCRIBE request. = If a server does A server MUST NOT = initiate an UNSUBSCRIBE message. If a = server does
send an = UNSUBSCRIBE request over a DSO session = initiated by a client, send an = UNSUBSCRIBE message over a DSO session = initiated by a client,
this is a = fatal error and the client should immediately abort the = this is a fatal error and the client should = immediately abort the
connection = with a TCP RST (or equivalent for other protocols). connection with a TCP RST (or equivalent for other = protocols).
=
6.4.1. = UNSUBSCRIBE Request 6.4.1. UNSUBSCRIBE Message
=
An = UNSUBSCRIBE request begins with the = standard DSO 12-byte header An = UNSUBSCRIBE unidirectional message begins = with the standard DSO
[DSO], followed by the UNSUBSCRIBE TLV. An = UNSUBSCRIBE request 12-byte header [RFC8490], followed by the UNSUBSCRIBE primary TLV.
message is = illustrated in Figure 3. An = UNSUBSCRIBE message is illustrated in Figure 3.
=
The MESSAGE ID field MUST be zero. There is no = server response to a In accordance with the = definition of DSO unidirectional messages, the
= MESSAGE ID field MUST be zero. There is no = server response to an
UNSUBSCRIBE = message. UNSUBSCRIBE = message.
=
The other = header fields MUST be set as described in the DSO The other header fields MUST be set as described in = the DSO spec-
specification [DSO]. The DNS Opcode is the DSO = Opcode. The four ification [RFC8490]. The DNS OPCODE field contains the OPCODE value
count fields = MUST be zero, and the corresponding four sections MUST for DNS Stateful Operations = (6). The four count fields MUST be zero,
be empty = (i.e., absent). and the = corresponding four sections MUST be empty (i.e., absent).
=
In the UNSUBSCRIBE TLV the DSO-TYPE is = UNSUBSCRIBE. The DSO-LENGTH= The DSO-TYPE = is UNSUBSCRIBE (tentatively 0x42).
is 2 octets.
=
The DSO-DATA contains the MESSAGE ID field of the value given = in the The DSO-LENGTH field contains the value 2, the length of = the 2-octet
ID field of an active SUBSCRIBE request. This is how = the server MESSAGE ID contained in the DSO-DATA.
knows which SUBSCRIBE request is being cancelled. = After receipt of
the UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. =
=
It is = allowable for the client to issue an UNSUBSCRIBE request for a = The DSO-DATA contains the value given in the = MESSAGE ID field of an
= active SUBSCRIBE = request. This is how the server knows which
= SUBSCRIBE request is = being cancelled. After receipt of the
= UNSUBSCRIBE message, = the SUBSCRIBE request is no longer active.
= =
= It is allowable for the client to issue an = UNSUBSCRIBE message for a
previous = SUBSCRIBE request for which the client has not yet received = previous SUBSCRIBE request for which the = client has not yet received
a SUBSCRIBE = response. This is to allow for the case where a client = a SUBSCRIBE response. This is to allow for = the case where a client
starts and = stops a subscription in less than the round-trip time to = starts and stops a subscription in less than = the round-trip time to
the server. = The client is NOT required to wait for the SUBSCRIBE the server. The client is NOT required to wait for = the SUBSCRIBE
response = before issuing the UNSUBSCRIBE request. = response before issuing the UNSUBSCRIBE message.
=
= Consequently, it is = possible for a server to receive an UNSUBSCRIBE
= message that does = not match any currently active subscription. This
= can occur when a = client sends a SUBSCRIBE request, which subsequently
= fails and returns an = error code, but the client sent an UNSUBSCRIBE
= message before it = became aware that the SUBSCRIBE request had failed.
= Because of this, = servers MUST silently ignore UNSUBSCRIBE messages
= that do not match = any currently active subscription.
=
= 1 1 1 1 1 1 = 1 1 1 1 1 1
0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = MESSAGE ID (MUST BE ZERO) | \ | MESSAGE ID (MUST BE ZERO) | = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
|QR| = Opcode | Z | RCODE = | | |QR| OPCODE(6) | Z | RCODE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER
| = ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
| DSO-TYPE =3D UNSUBSCRIBE = | | DSO-TYPE =3D UNSUBSCRIBE (tentatively 0x42) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| = DSO-LENGTH (2 octets) = | | DSO-LENGTH (2) |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = SUBSCRIBE MESSAGE ID | > DSO-DATA | SUBSCRIBE MESSAGE ID | = > DSO-DATA
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
=
= Figure 3: UNSUBSCRIBE Request = Figure 3: UNSUBSCRIBE Message
=
6.5. DNS Push = Notification RECONFIRM 6.5. DNS Push = Notification RECONFIRM
=
Sometimes, = particularly when used with a Discovery Proxy [DisProx], a = Sometimes, particularly when used with a = Discovery Proxy [DisProx], a
DNS Zone may = contain stale data. When a client encounters data that = DNS Zone may contain stale data. When a = client encounters data that
it believe = may be stale (e.g., an SRV record referencing a target it believes may be = stale (e.g., an SRV record referencing a target
host+port that = is not responding to connection requests) the client host+port that is not responding to connection = requests) the client
can send a = RECONFIRM request to ask the server to = re-verify that the can send a = RECONFIRM message to ask the server to = re-verify that the
data is still = valid. For a Discovery Proxy, this causes it to issue data is still valid. For a Discovery Proxy, this = causes it to issue
new = Multicast DNS requests to ascertain = whether the target device is new = Multicast DNS queries to ascertain whether = the target device is
still = present. For other types of DNS server, = the RECONFIRM still present. How = the Discovery Proxy causes these new = Multicast
operation is currently undefined, and SHOULD result = in a NOERROR DNS queries to be issued= depends on the details of the = underlying
response, but otherwise need not cause any = action to occur. Frequent = Multicast DNS = implementation being used. For example, a Discovery
RECONFIRM operations may be a sign of network unreliability, or = some = Proxy built on Apple's dns_sd.h API responds to a DNS Push
kind of misconfiguration, so RECONFIRM operations MAY be logged = or = Notification RECONFIRM message by calling the underlying = API's
otherwise communicated to a human administrator to assist in DNSServiceReconfirmRecord() routine.
detecting, and remedying, such network = problems.
=
If, after = receiving a valid RECONFIRM request, the = server determines For other types of DNS server, the RECONFIRM operation = is currently
= undefined, and = SHOULD result in a NOERROR response, but otherwise
= need not cause any = action to occur.
=
= Frequent use of = RECONFIRM operations may be a sign of network
= unreliability, or = some kind of misconfiguration, so RECONFIRM
= operations MAY be = logged or otherwise communicated to a human
= administrator to = assist in detecting, and remedying, such network
= = problems.
= =
= If, after receiving a valid RECONFIRM message, the server determines
that the = disputed records are in fact no longer valid, then that the disputed records are in fact no longer = valid, then
subsequent DNS = PUSH Messages will be generated to inform interested subsequent DNS PUSH Messages will be generated to = inform interested
clients. = Thus, one client discovering that a previously-advertised = clients. Thus, one client discovering that = a previously-advertised
device (like a = network printer) is no longer present has the side device (like a network printer) is no longer present = has the side
effect of = informing all other interested clients that the device in = effect of informing all other interested = clients that the device in
question is = now gone. question is now = gone.
=
6.5.1. = RECONFIRM Request 6.5.1. RECONFIRM Message
=
A RECONFIRM = request begins with the standard DSO = 12-byte header A RECONFIRM unidirectional message begins with the standard = DSO
[DSO], followed by the primary DSO RECONFIRM TLV. A RECONFIRM = 12-byte header [RFC8490], followed by the RECONFIRM primary TLV.
request message is illustrated in Figure = 4. A RECONFIRM message is = illustrated in Figure 4.
=
The MESSAGE ID field MUST be set to a unique value, = that the client In accordance with the = definition of DSO unidirectional messages, the
is not using for any other active operation on = this DSO session. For = MESSAGE ID field = MUST be zero. There is no server response = to a
the purposes here, a MESSAGE ID is in use on this session if the RECONFIRM message.
client has used it in a request for which it has not = yet received a
response, or if the client has used it for a = subscription which it
has not yet cancelled using UNSUBSCRIBE. In = the RECONFIRM response =
the server MUST echo back the MESSAGE ID value = unchanged.
=
The other = header fields MUST be set as described in the DSO The other header fields MUST be set as described in = the DSO spec-
specification [DSO]. The DNS Opcode is the DSO = Opcode. The four ification [RFC8490]. The DNS OPCODE field contains the OPCODE value
count fields = MUST be zero, and the corresponding four sections MUST for DNS Stateful Operations = (6). The four count fields MUST be zero,
be empty = (i.e., absent). and the = corresponding four sections MUST be empty (i.e., absent).
=
The DSO-TYPE = is RECONFIRM (tentatively 0x43). The DSO-LENGTH is the = The DSO-TYPE is RECONFIRM (tentatively = 0x43).
length of = the data that follows, which specifies the name, type, =
class, and = content of the record being disputed. = The DSO-LENGTH is the length of the data that follows, which
= specifies the name, type, class, and = content of the record being
= disputed.
=
= 1 1 1 1 1 1 = 1 1 1 1 1 1
0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
| = MESSAGE ID | \ | MESSAGE ID | = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
|QR| Opcode | Z | RCODE | = | |QR| OPCODE(6) | Z | RCODE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = HEADER
| = ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
| DSO-TYPE =3D RECONFIRM = | | DSO-TYPE =3D RECONFIRM (tentatively 0x43) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| = DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = \
\ = NAME \ \ \ NAME \ = \
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
| = TYPE | | | TYPE | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = DSO-DATA = +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > = DSO-DATA
| = CLASS | | | CLASS | = |
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = |
\ = RDATA \ / \ RDATA \ = /
= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ = /
=
= Figure 4: RECONFIRM Request= Figure 4: RECONFIRM = Message
=
The DSO-DATA = for a RECONFIRM request MUST contain = exactly one record. The DSO-DATA = for a RECONFIRM message MUST contain = exactly one record.
The DSO-DATA = for a RECONFIRM request has no count field = to specify The DSO-DATA for a = RECONFIRM message has no count field to = specify
more than = one record. Since RECONFIRM requests are = sent over TCP, more than one = record. Since RECONFIRM messages are sent = over TCP,
multiple = RECONFIRM request messages can be = concatenated in a single multiple = RECONFIRM messages can be concatenated in a single TCP
TCP stream = and packed efficiently into TCP segments. stream and packed efficiently into TCP = segments.
=
TYPE MUST NOT = be the value ANY (255) and CLASS MUST NOT be the value TYPE MUST NOT be the value ANY (255) and CLASS MUST = NOT be the value
ANY = (255). ANY (255).
=
DNS = wildcarding is not supported. That is, a wildcard ("*") in a = DNS wildcarding is not supported. That is, = a wildcard ("*") in a
RECONFIRM = message matches only a literal wildcard character ("*") in = RECONFIRM message matches only a literal = wildcard character ("*") in
the zone, and = nothing else. the zone, and nothing = else.
=
Aliasing is = not supported. That is, a CNAME in a RECONFIRM message = Aliasing is not supported. That is, a CNAME = in a RECONFIRM message
matches only a = literal CNAME record in the zone, and nothing else. matches only a literal CNAME record in the zone, and = nothing else.
=
6.5.2. RECONFIRM Response
Each RECONFIRM request generates exactly one = RECONFIRM response from
the server.
A RECONFIRM response message begins with the = standard DSO 12-byte
header [DSO], possibly followed by one or more = optional TLVs, such as
a Retry Delay TLV. For suggested values for the = Retry Delay TLV, see
Section 6.2.2.
The MESSAGE ID field MUST echo the value given in = the ID field of the
RECONFIRM request. This is how the client knows = which request is
being responded to.
A RECONFIRM response message MUST NOT include a DSO = RECONFIRM TLV.
If a client receives a RECONFIRM response message = containing a
RECONFIRM TLV then the response message is processed = but the
RECONFIRM TLV MUST be silently = ignored.
In the RECONFIRM response the RCODE confirms receipt = of the
reconfirmation request. Supported RCODEs are as = follows:
= +-----------+-------+-----------------------------------------------+
| Mnemonic | Value | Description = |
= +-----------+-------+-----------------------------------------------+
| NOERROR | 0 | RECONFIRM accepted. = |
| FORMERR | 1 | Server failed to process = request due to a |
| | | malformed request. = |
| SERVFAIL | 2 | Server failed to process = request due to a |
| | | problem with the server. = |
| NOTIMP | 4 | Server does not implement DSO. = |
| REFUSED | 5 | Server refuses to process = request for policy |
| | | or security reasons. = |
| NOTAUTH | 9 | Server is not authoritative = for the requested |
| | | name. = |
| DSOTYPENI | 11 | RECONFIRM operation not = supported. |
= +-----------+-------+-----------------------------------------------+
Table 2: RECONFIRM Response = codes
This document specifies only these RCODE values for = RECONFIRM
Responses. Servers sending RECONFIRM Responses = SHOULD use one of
these values. Note that NXDOMAIN is not a valid = RCODE in response to
a RECONFIRM Request. However, future circumstances = may create
situations where other RCODE values are appropriate = in RECONFIRM
Responses, so clients MUST be prepared to accept = RECONFIRM Responses
with any other RCODE value.
Nonzero RCODE values signal some kind of = error.
RCODE value FORMERR indicates a message format = error, for example
TYPE or CLASS being ANY (255). =
RCODE value SERVFAIL indicates that the server has = exhausted its
resources or other serious problem = occurred.
RCODE values NOTIMP indicates that the server does = not support DSO,
and DSO is required for RECONFIRM = requests.
RCODE value REFUSED indicates that the server = supports RECONFIRM
requests but is currently not configured to accept = them from this
client.
RCODE value NOTAUTH indicates that the server is not = authoritative
for the requested name, and can do nothing to remedy = the apparent
error. Note that there may be future cases in which = a server is able
to pass on the RECONFIRM request to the ultimate = source of the
information, and in these cases the server should = return NOERROR.
RCODE value DSOTYPENI indicates that the server does = not support
RECONFIRM requests.
Nonzero RCODE values SERVFAIL, REFUSED and DSOTYPENI = are benign from
the client's point of view. The client may log them = to aid in
debugging, but otherwise they require no special = action.
Nonzero RCODE values other than these three indicate = a serious
problem with the client. After sending an error = response other than
one of these three, the server SHOULD send a DSO = Retry Delay TLV to
end the DSO session, as described in the DSO = specification [DSO].
= =
6.6. DNS = Stateful Operations TLV Context Summary 6.6. DNS Stateful Operations TLV Context = Summary
=
This = document defines four new DSO TLVs. As suggested in [DSO], = This document defines four new DSO TLVs. As suggested in Section 8.2
Section = 8.2, the valid contexts of these new TLV = types are summarized of the DNS Stateful Operations specification = [RFC8490], the valid
= below. contexts of these new TLV = types are summarized below.
=
The client TLV = contexts are: The client TLV = contexts are:
=
C-P: Client = primary TLV C-P: Client request message, primary TLV
C-U: Client = primary unidirectional TLV = C-U: Client unidirectional message, primary TLV
C-A: Client = additional TLV C-A: Client request or unidirectional message, additional = TLV
CRP: Client response primary TLV CRP: Response back to = client, primary TLV
CRA: Client response additional TLV CRA: Response back to = client, additional TLV
=
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
| = TLV Type | C-P | C-U | C-A | CRP | CRA | | TLV Type | C-P | C-U | C-A | CRP | = CRA |
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
| = SUBSCRIBE | X | | | | | | SUBSCRIBE | X | | | | = |
| = PUSH | | | | | | | PUSH | | | | | = |
| = UNSUBSCRIBE | | X | | | | | UNSUBSCRIBE | | X | | | = |
| = RECONFIRM | X | | | | | | RECONFIRM | X | | | | = |
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
=
= Table 3: DSO TLV Client Context = Summary Table 2: DSO TLV Client Context Summary
=
The server TLV = contexts are: The server TLV = contexts are:
=
S-P: Server = primary TLV S-P: Server request message, primary TLV
S-U: Server = primary unidirectional TLV = S-U: Server unidirectional message, primary TLV
S-A: Server = additional TLV S-A: Server request or unidirectional message, additional = TLV
SRP: Server response primary TLV SRP: Response back to = server, primary TLV
SRA: Server response additional TLV SRA: Response back to = server, additional TLV
=
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
| = TLV Type | S-P | S-U | S-A | SRP | SRA | | TLV Type | S-P | S-U | S-A | SRP | = SRA |
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
| = SUBSCRIBE | | | | | | | SUBSCRIBE | | | | | = |
| = PUSH | | X | | | | | PUSH | | X | | | = |
| = UNSUBSCRIBE | | | | | | | UNSUBSCRIBE | | | | | = |
| = RECONFIRM | | | | | | | RECONFIRM | | | | | = |
= +-------------+-----+-----+-----+-----+-----+ = +-------------+-----+-----+-----+-----+-----+
=
= Table 4: DSO TLV Server Context = Summary Table 3: DSO TLV Server Context Summary
=
6.7. = Client-Initiated Termination 6.7. = Client-Initiated Termination
=
An individual = subscription is terminated by sending an UNSUBSCRIBE An individual subscription is terminated by sending = an UNSUBSCRIBE
TLV for that = specific subscription, or all subscriptions can be TLV for that specific subscription, or all = subscriptions can be
cancelled at = once by the client closing the DSO session. When a cancelled at once by the client closing the DSO = session. When a
client = terminates an individual subscription (via UNSUBSCRIBE) or all = client terminates an individual subscription = (via UNSUBSCRIBE) or all
subscriptions = on that DSO session (by ending the session) it is subscriptions on that DSO session (by ending the = session) it is
signaling to = the server that it is longer interested in receiving signaling to the server that it is longer interested = in receiving
those = particular updates. It is informing the server that the server = those particular updates. It is informing = the server that the server
may release = any state information it has been keeping with regards to = may release any state information it has = been keeping with regards to
these = particular subscriptions. these = particular subscriptions.
=
After = terminating its last subscription on a session via UNSUBSCRIBE, = After terminating its last subscription on a = session via UNSUBSCRIBE,
a client MAY = close the session immediately, or it may keep it open if = a client MAY close the session immediately, = or it may keep it open if
it anticipates = performing further operations on that session in the it anticipates performing further operations on that = session in the
future. If a = client wishes to keep an idle session open, it MUST future. If a client wishes to keep an idle session = open, it MUST
respect the = maximum idle time required by the server [DSO]. = respect the maximum idle time required by the server [RFC8490].
=
If a client = plans to terminate one or more subscriptions on a session = If a client plans to terminate one or more = subscriptions on a session
and doesn't = intend to keep that session open, then as an efficiency = and doesn't intend to keep that session = open, then as an efficiency
optimization = it MAY instead choose to simply close the session, which = optimization it MAY instead choose to simply = close the session, which
implicitly = terminates all subscriptions on that session. This may = implicitly terminates all subscriptions on = that session. This may
occur because = the client computer is being shut down, is going to occur because the client computer is being shut down, = is going to
sleep, the = application requiring the subscriptions has terminated, or = sleep, the application requiring the = subscriptions has terminated, or
simply because = the last active subscription on that session has been simply because the last active subscription on that = session has been
= cancelled. cancelled.
=
=
skipping = to change at page 30, line = 8 =C2=B6 = skipping to change at page 32, line = 8 =C2=B6
If a client = has performed operations on this session that it would If a client has performed operations on this session = that it would
not want lost = (like DNS updates) then the client SHOULD do an orderly = not want lost (like DNS updates) then the = client SHOULD do an orderly
disconnect, = sending a TLS close_notify followed by a TCP FIN. (In disconnect, sending a TLS close_notify followed by a = TCP FIN. (In
the BSD = Sockets API, sending a TCP FIN is achieved by calling the BSD Sockets API, sending a TCP FIN is achieved by = calling
= "shutdown(s,SHUT_WR)" and keeping the socket open until all = remaining "shutdown(s,SHUT_WR)" and = keeping the socket open until all remaining
data has been = read from it.) data has been read = from it.)
=
7. Security = Considerations 7. Security = Considerations
=
The Strict = Privacy Usage Profile for DNS over TLS is REQUIRED for DNS = The Strict Privacy Usage Profile for DNS = over TLS is REQUIRED for DNS
Push = Notifications as defined in "Usage Profiles for = DNS over TLS and Push = Notifications [RFC8310]. Cleartext connections for DNS Push
DNS over DTLS" [RFC8310]. Cleartext = connections for DNS Push
Notifications = are not permissible. Since this is a new protocol, Notifications are not permissible. Since this is a = new protocol,
transition = mechanisms from the Opportunistic Privacy profile are transition mechanisms from the Opportunistic Privacy = profile are
deemed unnecessary. unnecessary.
= =
= Also, see Section 9 = of the DNS over (D)TLS Usage Profiles document
= [RFC8310] for = additional recommendations for various versions of TLS
= = usage.
=
DNSSEC is = RECOMMENDED for the authentication of DNS Push Notification = DNSSEC is RECOMMENDED for the authentication = of DNS Push Notification
servers. TLS = alone does not provide complete security. TLS servers. TLS alone does not provide complete = security. TLS
certificate = verification can provide reasonable assurance that the certificate verification can provide reasonable = assurance that the
client is = really talking to the server associated with the desired = client is really talking to the server = associated with the desired
host name, but = since the desired host name is learned via a DNS SRV host name, but since the desired host name is learned = via a DNS SRV
query, if the = SRV query is subverted then the client may have a query, if the SRV query is subverted then the client = may have a
secure = connection to a rogue server. DNSSEC can provided added = secure connection to a rogue server. DNSSEC = can provided added
confidence = that the SRV query has not been subverted. confidence that the SRV query has not been = subverted.
=
=
skipping = to change at page 30, line = 52 =C2=B6 = skipping to change at page 33, line = 6 =C2=B6
= recommendations will continue to change. Updated versions or = errata recommendations will = continue to change. Updated versions or errata
may exist for = these recommendations. may exist = for these recommendations.
=
7.2. TLS Name = Authentication 7.2. TLS Name = Authentication
=
As described = in Section 6.1, the client discovers the DNS Push As described in Section 6.1, the client discovers the = DNS Push
Notification = server using an SRV lookup for the record name Notification server using an SRV lookup for the = record name
= "_dns-push-tls._tcp.<zone>". The server connection endpoint = SHOULD = "_dns-push-tls._tcp.<zone>". The server connection endpoint = SHOULD
then be = authenticated using DANE TLSA records for the associated SRV = then be authenticated using DANE TLSA = records for the associated SRV
record. This = associates the target's name and port number with a record. This associates the target's name and port = number with a
trusted TLS = certificate [RFC7673]. This procedure uses the TLS Sever = trusted TLS certificate [RFC7673]. This procedure uses the TLS
Name = Indication (SNI) extension [RFC6066] to inform the server of = the Server Name Indication (SNI) extension [RFC6066] = to inform the server
name the = client has authenticated through the use of TLSA records. = of the name the client has authenticated = through the use of TLSA
Therefore, = if the SRV record passes DNSSEC validation and a TLSA records. Therefore, if the SRV record passes DNSSEC = validation and a
record = matching the target name is useable, an SNI extension must be = TLSA record matching the target name is = useable, an SNI extension
used for the = target name to ensure the client is connecting to the must be used for the target name to ensure the = client is connecting
server it = has authenticated. If the target name does not have a to the server it has authenticated. If the target = name does not have
usable TLSA = record, then the use of the SNI extension is optional. a usable TLSA record, then the use of the SNI = extension is optional.
= =
See Usage = Profiles for DNS over TLS and DNS over DTLS [RFC8310] for = See Usage Profiles for DNS over TLS and DNS = over DTLS [RFC8310] for
more = information on authenticating domain names. Also = note that a more = information on authenticating domain names.
DNS Push server is an authoritative server and a DNS = Push client is a
standard DNS client. While the terminology in Usage = Profiles for DNS
over TLS and DNS over DTLS [RFC8310] explicitly = states it does not
apply to authoritative servers, it does in this case = apply to DNS
Push Notification clients and = servers.
7.3. TLS Compression
In order to reduce the chances of = compression-related attacks, TLS-
level compression SHOULD be disabled when using TLS = versions 1.2 and
earlier. In TLS 1.3 [RFC8446], TLS-level = compression has been
removed completely.
=
7.4. TLS Session Resumption 7.3. TLS Session = Resumption
=
TLS Session = Resumption is permissible on DNS Push Notification TLS Session Resumption is permissible on DNS Push = Notification
servers. = The server may keep TLS state with Session IDs [RFC5246] or = servers. The server may keep TLS state with Session IDs [RFC8446] or
operate in = stateless mode by sending a Session Ticket [RFC5077] to = operate in stateless mode by sending a = Session Ticket [RFC5077] to
the client for = it to store. However, closing the TLS connection the client for it to store. However, closing the TLS = connection
terminates the = DSO session. When the TLS session is resumed, the DNS terminates the DSO session. When the TLS session is = resumed, the DNS
Push = Notification server will not have any subscription state and = Push Notification server will not have any = subscription state and
will proceed = as with any other new DSO session. Use of TLS Session will proceed as with any other new DSO session. Use = of TLS Session
Resumption may = allow a TLS connection to be set up more quickly, but Resumption may allow a TLS connection to be set up = more quickly, but
the client = will still have to recreate any desired subscriptions. the client will still have to recreate any desired = subscriptions.
=
8. IANA = Considerations 8. IANA = Considerations
=
=
skipping = to change at page 32, line = 18 =C2=B6 = skipping to change at page 33, line = 42 =C2=B6
Registry = Service Types [RFC6335][ST] that is only applicable for the = Registry Service Types [RFC6335][ST] that is = only applicable for the
TCP = protocol. TCP protocol.
=
= +-----------------------+------+----------------------+-------------+ = +-----------------------+------+----------------------+-------------+
| Name = | Port | Value | Definition | | Name | Port | Value = | Definition |
= +-----------------------+------+----------------------+-------------+ = +-----------------------+------+----------------------+-------------+
| DNS Push = Notification | None | "_dns-push-tls._tcp" | Section 6.1 | = | DNS Push Notification | None | = "_dns-push-tls._tcp" | Section 6.1 |
| Service Type = | | | | | Service Type | | = | |
= +-----------------------+------+----------------------+-------------+ = +-----------------------+------+----------------------+-------------+
=
= Table 5: IANA Service Type = Assignments Table = 4: IANA Service Type Assignments
=
This document = also defines four new DNS Stateful Operation TLV types This document also defines four new DNS Stateful = Operation TLV types
to be recorded = in the IANA DSO Type Code Registry. = to be recorded in the IANA DSO Type Code Registry.
=
+-------------+------------------------+---------------+<= /span> +-------------+------------------------+-------------+
| Name = | Value | Definition | | Name | Value | = Definition |
+-------------+------------------------+---------------+<= /span> +-------------+------------------------+-------------+
| = SUBSCRIBE | TBA (tentatively 0x40) | Section 6.2 | | SUBSCRIBE | TBA (tentatively 0x40) | = Section 6.2 |
| PUSH = | TBA (tentatively 0x41) | Section 6.3.1 | = | PUSH | TBA (tentatively 0x41) | Section 6.3 |
| = UNSUBSCRIBE | TBA (tentatively 0x42) | Section 6.4 | | UNSUBSCRIBE | TBA (tentatively 0x42) | = Section 6.4 |
| = RECONFIRM | TBA (tentatively 0x43) | Section 6.5.1 | = | RECONFIRM | TBA (tentatively 0x43) | Section 6.5 |
+-------------+------------------------+---------------+<= /span> +-------------+------------------------+-------------+
=
= Table 6: IANA DSO TLV Type Code = Assignments Table = 5: IANA DSO TLV Type Code = Assignments
=
9. = Acknowledgements 9. = Acknowledgements
=
The authors = would like to thank Kiren Sekar and Marc Krochmal for The authors would like to thank Kiren Sekar and Marc = Krochmal for
previous work = completed in this field. previous = work completed in this field.
=
This draft has = been improved due to comments from Ran Atkinson, Tim This draft has been improved due to comments from Ran = Atkinson, Tim
Chown, Mark = Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan = Komissar, Manju
Shankar Rao, = Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara Shankar Rao, Markus Stenberg, Dave Thaler, Soraia = Zlatkovic, Sara
Dickinson, and = Andrew Sullivan. Ted Lemon provided clarifying text Dickinson, and Andrew Sullivan. Ted Lemon provided = clarifying text
that was = greatly appreciated. that was = greatly appreciated.
=
10. = References 10. References
=
10.1. Normative = References 10.1. Normative = References
=
[DSO] Bellis, R., Cheshire, S., Dickinson, J., = Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful = Operations",
draft-ietf-dnsop-session-signal-18 (work = in progress),
October 2018.
= =
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0793] = Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control = Protocol", STD 7,
RFC = 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September = 1981,
= <https://www.rfc-editor.org/info/rfc793>. = <https://www.rfc-editor.org/info/rfc793>.
=
[RFC1034] = Mockapetris, P., "Domain names - concepts and facilities", = [RFC1034] Mockapetris, P., "Domain names - = concepts and facilities",
STD = 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, = November 1987,
=
skipping = to change at page 33, line = 45 =C2=B6 = skipping to change at page 35, line = 15 =C2=B6
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
= Requirement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DOI = 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2119>. = <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2136] = Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, = [RFC2136] Vixie, P., Ed., Thomson, S., = Rekhter, Y., and J. Bound,
= "Dynamic Updates in the Domain Name System (DNS UPDATE)", = "Dynamic Updates in the Domain = Name System (DNS UPDATE)",
RFC = 2136, DOI 10.17487/RFC2136, April 1997, = RFC 2136, DOI 10.17487/RFC2136, April 1997,
= <https://www.rfc-editor.org/info/rfc2136>. = <https://www.rfc-editor.org/info/rfc2136>.
=
= [RFC2181] Elz, R. = and R. Bush, "Clarifications to the DNS
= = Specification", RFC 2181, DOI 10.17487/RFC2181, July = 1997,
= = <https://www.rfc-editor.org/info/rfc2181>.
= =
[RFC2782] = Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for = [RFC2782] Gulbrandsen, A., Vixie, P., and = L. Esibov, "A DNS RR for
= specifying the location of services (DNS SRV)", RFC 2782, = specifying the location of = services (DNS SRV)", RFC 2782,
DOI = 10.17487/RFC2782, February 2000, = DOI 10.17487/RFC2782, February 2000,
= <https://www.rfc-editor.org/info/rfc2782>. = <https://www.rfc-editor.org/info/rfc2782>.
=
[RFC5246] Dierks, T. and E. Rescorla, "The Transport = Layer Security
(TLS) Protocol Version 1.2", RFC = 5246,
DOI 10.17487/RFC5246, August = 2008,
= <https://www.rfc-editor.org/info/rfc5246>. =
= =
[RFC6066] = Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer = Security (TLS)
= Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC = 6066,
DOI = 10.17487/RFC6066, January 2011, = DOI 10.17487/RFC6066, January 2011,
= <https://www.rfc-editor.org/info/rfc6066>. = <https://www.rfc-editor.org/info/rfc6066>.
=
[RFC6335] = Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. = [RFC6335] Cotton, M., Eggert, L., Touch, = J., Westerlund, M., and S.
= Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers = Authority (IANA)
= Procedures for the Management of the Service Name and Procedures for the Management of the = Service Name and
= Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", = BCP 165,
RFC = 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August = 2011,
=
skipping = to change at page 34, line = 44 =C2=B6 = skipping to change at page 36, line = 9 =C2=B6
= <https://www.rfc-editor.org/info/rfc7766>. = <https://www.rfc-editor.org/info/rfc7766>.
=
[RFC8174] = Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs = Lowercase in RFC
= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, = 2119 Key Words", BCP 14, RFC = 8174, DOI 10.17487/RFC8174,
May = 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, = <https://www.rfc-editor.org/info/rfc8174>.
=
[RFC8446] = Rescorla, E., "The Transport Layer Security (TLS) Protocol = [RFC8446] Rescorla, E., "The Transport = Layer Security (TLS) Protocol
= Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, = Version 1.3", RFC 8446, DOI = 10.17487/RFC8446, August 2018,
= <https://www.rfc-editor.org/info/rfc8446>. = <https://www.rfc-editor.org/info/rfc8446>.
=
= [RFC8490] Bellis, = R., Cheshire, S., Dickinson, J., Dickinson, S.,
= Lemon, = T., and T. Pusateri, "DNS Stateful Operations",
= RFC 8490, = DOI 10.17487/RFC8490, March 2019,
= = <https://www.rfc-editor.org/info/rfc8490>.
= =
[ST] = "Service Name and Transport Protocol Port Number [ST] "Service Name and Transport Protocol Port = Number
= Registry", <http://www.iana.org/assignments/ Registry", = <http://www.iana.org/assignments/
= service-names-port-numbers/>. = service-names-port-numbers/>.
=
10.2. = Informative References 10.2. = Informative References
=
[DisProx] = Cheshire, S., "Discovery Proxy for Multicast DNS-Based [DisProx] Cheshire, S., "Discovery Proxy for = Multicast DNS-Based
= Service Discovery", draft-ietf-dnssd-hybrid-08 (work in = Service Discovery", draft-ietf-dnssd-hybrid-10 (work in
= progress), March 2018. progress), March 2019.
=
= [I-D.dukkipati-tcpm-tcp-loss-probe] = [I-D.dukkipati-tcpm-tcp-loss-probe]
= Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, Dukkipati, N., Cardwell, N., Cheng, Y., = and M. Mathis,
= "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of = "Tail Loss Probe (TLP): An = Algorithm for Fast Recovery of
= Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work = Tail Losses", = draft-dukkipati-tcpm-tcp-loss-probe-01 (work
in = progress), February 2013. = in progress), February 2013.
=
[LLQ] = Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- [LLQ] Cheshire, S. and = M. Krochmal, "DNS Long-Lived Queries",
llq-01 (work in progress), August 2006. = draft-sekar-dns-llq-03 (work = in progress), March 2019.
=
[obs] = "Observer Pattern", [obs] = "Observer Pattern",
= <https://en.wikipedia.org/wiki/Observer_pattern>. = = <https://en.wikipedia.org/wiki/Observer_pattern>.
=
[RFC2308] = Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS = Queries (DNS
= NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, = March 1998,
= <https://www.rfc-editor.org/info/rfc2308>. = <https://www.rfc-editor.org/info/rfc2308>.
=
= [RFC3123] Koch, P., = "A DNS RR Type for Lists of Address Prefixes
= (APL = RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001,
= = <https://www.rfc-editor.org/info/rfc3123>.
= =
[RFC4287] = Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., = "The Atom
= Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI = 10.17487/RFC4287,
= December 2005, <https://www.rfc-editor.org/info/rfc4287>. = December 2005, = <https://www.rfc-editor.org/info/rfc4287>.
=
[RFC4953] = Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing = Attacks",
RFC = 4953, DOI 10.17487/RFC4953, July 2007, = RFC 4953, DOI 10.17487/RFC4953, July 2007,
= <https://www.rfc-editor.org/info/rfc4953>. = <https://www.rfc-editor.org/info/rfc4953>.
=
[RFC5077] = Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. = Tschofenig,
= "Transport Layer Security (TLS) Session Resumption without = "Transport Layer Security (TLS) = Session Resumption without
=
skipping = to change at page 36, line = 5 =C2=B6 = skipping to change at page 37, line = 28 =C2=B6
=
[RFC6763] = Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based = Service
= Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, = Discovery", RFC 6763, DOI = 10.17487/RFC6763, February 2013,
= <https://www.rfc-editor.org/info/rfc6763>. = <https://www.rfc-editor.org/info/rfc6763>.
=
[RFC6824] = Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. = Bonaventure,
= "TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation = with Multiple
= Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, = Addresses", RFC 6824, DOI = 10.17487/RFC6824, January 2013,
= <https://www.rfc-editor.org/info/rfc6824>. = <https://www.rfc-editor.org/info/rfc6824>.
=
= [RFC6886] Cheshire, = S. and M. Krochmal, "NAT Port Mapping Protocol
= = (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013,
= = <https://www.rfc-editor.org/info/rfc6886>.
=
= [RFC6887] Wing, D., = Ed., Cheshire, S., Boucadair, M., Penno, R., and
= P. = Selkirk, "Port Control Protocol (PCP)", RFC 6887,
= DOI = 10.17487/RFC6887, April 2013,
= = <https://www.rfc-editor.org/info/rfc6887>.
= =
[RFC7413] = Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP = [RFC7413] Cheng, Y., Chu, J., = Radhakrishnan, S., and A. Jain, "TCP
= Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, = Fast Open", RFC 7413, DOI = 10.17487/RFC7413, December 2014,
= <https://www.rfc-editor.org/info/rfc7413>. = <https://www.rfc-editor.org/info/rfc7413>.
=
[RFC7525] = Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. = Saint-Andre,
= "Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of = Transport Layer
= Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport = Layer Security
= (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI = 10.17487/RFC7525, May
= 2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, = <https://www.rfc-editor.org/info/rfc7525>.
=
=
skipping = to change at page 37, line = 17 =C2=B6 = skipping to change at page 38, line = 44 =C2=B6
Tom = Pusateri Tom Pusateri
= Unaffiliated Unaffiliated
Raleigh, NC = 27608 Raleigh, NC 27608
USA = USA
=
Phone: +1 919 = 867 1330 Phone: +1 919 867 = 1330
Email: = pusateri@bangj.com Email: = pusateri@bangj.com
=
Stuart = Cheshire Stuart Cheshire
Apple = Inc. Apple Inc.
1 Infinite Loop One Apple Park = Way
Cupertino, CA = 95014 Cupertino, CA 95014
USA = USA
=
Phone: +1 = 408 974 3207 Phone: +1 (408) = 996-1010
Email: = cheshire@apple.com Email: = cheshire@apple.com
 End of changes. 120 change = blocks. 
455 lines changed or = deleted 506 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Boundary_(ID_Wq1XeBIaw82Bwu0++WUYSg)-- From nobody Sun Apr 28 17:07:06 2019 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 31FC1120121 for ; Sun, 28 Apr 2019 17:07:04 -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 MOd-oo-ULJc0 for ; Sun, 28 Apr 2019 17:07:01 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 80BFA12004C for ; Sun, 28 Apr 2019 17:07:01 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id y8so1321250ljd.3 for ; Sun, 28 Apr 2019 17:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vxoDqj4UKenebMbzliyVqa59HFxvLIiam0Fzc8FgT8Q=; b=Vsn4VfXLFh77my7G4drVajtQdr3rUEmvu6xpWdf6vlgtiwpLzZacbfmkV+jVy+WRk7 7huFGpJBvOcLgwlkYh8ehqAUsyL4boPANUv2aoX1yOLwmMPxFif5NRjnfvzLhGMtqtzR m1LGQkUn+z6y7FXQzrSHNUPKSuHhqxVr3JbZ/70Fb1im/GwDJ8PAEoRAtN2l/i+XiJNZ QpF5uDr2gvVxoccvxZtCuk+OAcNmq9WlpaD/1K5v3HOv8TM4fzkfyw/yevjIr7Ns15u/ Zm5I62bqGghUKCP+ftKI4xdTYOfb+hUlqhGdpKl/FtxXju0aZnZlDrPTWYAEib1UgYHE mx0A== 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=vxoDqj4UKenebMbzliyVqa59HFxvLIiam0Fzc8FgT8Q=; b=kEeuS9HK8k/Un3b4AUIPann/Yc7XwdrwTWgCdRal+q6PvAETVpNER8x7NtGjlqRxLt ZYUTrN3mQHpyFtxu4HhkNvkz2I0QR9iRMfj7naVWXKchF+GCW/k2jSV82IqmHv4B951N kr/ylD5ekv2i+KQ453RR0CkVclNaxf4s+MfRKLqeAhobnpK7p1qDDpfkcp9jUbA3iGHY EK1HXJwezIIZYm9opHjORwZt54ygLrA/76w5OZjcz1Rqx0rqdGTI3lYig0sbryV2P/hM loMF2D4tFBp3PqmFCh+pIEt0XidlhuC7O1l32Ya6lllmTfBrB/ir3WOWo6Uw8tqFWCXC 2CXg== X-Gm-Message-State: APjAAAXT7uLGgtoACL8ompW4ZpF8+wGJSfW4xFKMUvmgRsDqO/JjbZNq Bfg2k3dXdLmt2lYdBnLPbo3w7tr8D2CX1+ejb+gl9zGG X-Google-Smtp-Source: APXvYqyEyUVuEIakIihmcytV9+H2r0a+doEsavkGFJC36Zt/TxWVFYM1dIVS9is6B3P9TLFzPQd+xjNIJtuyxb2WFoI= X-Received: by 2002:a2e:8556:: with SMTP id u22mr4324471ljj.120.1556496419530; Sun, 28 Apr 2019 17:06:59 -0700 (PDT) MIME-Version: 1.0 References: <19C8C2DA-8B57-44B2-9457-DCB395D95D62@apple.com> In-Reply-To: <19C8C2DA-8B57-44B2-9457-DCB395D95D62@apple.com> From: David Schinazi Date: Sun, 28 Apr 2019 17:06:48 -0700 Message-ID: To: Stuart Cheshire Cc: DNSSD Content-Type: multipart/alternative; boundary="0000000000002e2c430587a01061" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-push X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 29 Apr 2019 00:07:04 -0000 --0000000000002e2c430587a01061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Stuart. To give working group members time to review this diff and your email, we are extending this WGLC by a week, until 2019-05-06. For future reference, you can use rfcdiff with published draft names in the URL: https://tools.ietf.org//rfcdiff?url1=3Ddraft-ietf-dnssd-push-16&url2=3Ddraf= t-ietf-dnssd-push-19 Speaking with WG chair hat off, I personally do not see any problem with these changes and support publication. Thanks, David On Thu, Apr 25, 2019 at 10:13 PM Stuart Cheshire wrote: > On 15 Apr 2019, at 10:07, David Schinazi wrote= : > > > This email starts another Working Group Last Call (WGLC) for > draft-ietf-dnssd-push, which will last for two weeks until 2019-04-29. As= a > reminder, this document has already passed WGLC but some slight changes t= o > the document warranted another WGLC. > > Thank you David. > > I have attached an HTML file of the output from < > https://tools.ietf.org/rfcdiff> comparing draft-ietf-dnssd-push-16 with > draft-ietf-dnssd-push-19. > > There are a variety of minor textual changes, such as replacing reference= s > to draft-ietf-dnsop-session-signal with references to RFC 8490, now that > this document is published. > > In terms of substantive changes, there are two: > > 1. DNS Push Notification RECONFIRM > > We realized that there is no useful response to a RECONFIRM request. We > changed RECONFIRM to be a unidirectional DSO message, and that results in > the deletion of the entire =E2=80=9CRECONFIRM Response=E2=80=9D section. = This simplifies > both code, and the document. > > 2. DNS Push Notification Updates > > Previously, Tom Pusateri and I thought that borrowing the DNS Update > encoding made sense. That was before DSO (RFC 8490). > > When implementing the current specification of DNS Push Notifications ove= r > DSO, Ted Lemon discovered that it has no way to express the DNS CLASS of > changes. > > We need to address the problem Ted Lemon discovered, and now that DNS Pus= h > uses DSO TLV encoding instead of traditional DNS messages, the incentive = to > follow strictly the existing DNS Update encoding has disappeared. > > To address this issue, we adopted a new, simpler, way of expressing > changes. It=E2=80=99s broadly similar, but simpler. > > Please take a look at these changes and let us know if you see any > problems. > > And if you *don=E2=80=99t* see any problems with these changes, please re= spond > saying that too. > > Stuart Cheshire > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000002e2c430587a01061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Stuart.

To g= ive working group members time to review this diff and your email, we are e= xtending this WGLC by a week, until 2019-05-06.

Fo= r future reference, you can use rfcdiff with published draft names in the U= RL:

Speaking with WG chair hat off, I personally = do not see any problem with these changes and support publication.

Thanks,
David

On Thu, Apr = 25, 2019 at 10:13 PM Stuart Cheshire <cheshire=3D40apple.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 15 Apr 2019, at 10:07, = David Schinazi <dschinazi.ietf@gmail.com> wrote:

> This email starts another Working Group Last Call (WGLC) for draft-iet= f-dnssd-push, which will last for two weeks until 2019-04-29. As a reminder= , this document has already passed WGLC but some slight changes to the docu= ment warranted another WGLC.

Thank you David.

I have attached an HTML file of the output from <https://tools.ietf= .org/rfcdiff> comparing draft-ietf-dnssd-push-16 with draft-ietf-dns= sd-push-19.

There are a variety of minor textual changes, such as replacing references = to draft-ietf-dnsop-session-signal with references to RFC 8490, now that th= is document is published.

In terms of substantive changes, there are two:

1. DNS Push Notification RECONFIRM

We realized that there is no useful response to a RECONFIRM request. We cha= nged RECONFIRM to be a unidirectional DSO message, and that results in the = deletion of the entire =E2=80=9CRECONFIRM Response=E2=80=9D section. This s= implifies both code, and the document.

2. DNS Push Notification Updates

Previously, Tom Pusateri and I thought that borrowing the DNS Update encodi= ng made sense. That was before DSO (RFC 8490).

When implementing the current specification of DNS Push Notifications over = DSO, Ted Lemon discovered that it has no way to express the DNS CLASS of ch= anges.

We need to address the problem Ted Lemon discovered, and now that DNS Push = uses DSO TLV encoding instead of traditional DNS messages, the incentive to= follow strictly the existing DNS Update encoding has disappeared.

To address this issue, we adopted a new, simpler, way of expressing changes= . It=E2=80=99s broadly similar, but simpler.

Please take a look at these changes and let us know if you see any problems= .

And if you *don=E2=80=99t* see any problems with these changes, please resp= ond saying that too.

Stuart Cheshire

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000002e2c430587a01061-- From nobody Mon Apr 29 08:38:55 2019 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 79D841201BE for ; Mon, 29 Apr 2019 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SSiRImKl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GfyNzFPP 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 5xcSyCJ2Vh6C for ; Mon, 29 Apr 2019 08:38:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAFC120162 for ; Mon, 29 Apr 2019 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13397; q=dns/txt; s=iport; t=1556552331; x=1557761931; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lyTouNkvFLKyjTFUH7u9GVmk5T4dQK9KRnfKcTctslw=; b=SSiRImKlYJreDzUELJ1hnF4ZkkE2flY6CItz/ouxwj0VEiRcKOm52feF /M9xpD2JPB78PMpTO5P20Td91+W38SJJgOW48o8ab99+EN22jcR85gmPh cZeXhHJRvNMOnuM9nFA/0RQZqsPTSMypbVzkDZiICFBpPh6xj9ojQq+Xv U=; IronPort-PHdr: =?us-ascii?q?9a23=3ATpoudRMWOIEgpI07kNQl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj5L/nvbjchFexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAABVGcdc/5tdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANoVSAECygKhAaDRwOEUoo7gjI?= =?us-ascii?q?liT6JGIRMgS4UgRADVA4BARgBDAiDCYE3AheGGyM0CQ4BAwEBBAEBAgECbRw?= =?us-ascii?q?MhUoBAQEDAQEBEBEdAQEsCwEECwIBCA4DAwECKAMCAgIfBgsUCQgCBAENBSK?= =?us-ascii?q?DAAGBHUwDDQ8BDqJ2AoE1iF9xgS+CeQEBBYE2AoEPgjUNC4IOAwaBMgGLSRe?= =?us-ascii?q?BQD+BEScME4JMPoIaRwEBAgEXgRAEARIBPw0JglQygiaNPIREh3eMSzkJAoI?= =?us-ascii?q?JhhGDb4Rmg00bgg2GNIxmizYJToEehSOBSIxEAgQCBAUCDgEBBYFPOGVxcBU?= =?us-ascii?q?7KgGCQYFrJINvhRSFP3IBgSiQPw8XgQsBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.60,409,1549929600"; d="scan'208,217";a="268832618" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 15:38:50 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TFcoqk020566 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 15:38:50 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 10:38:49 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 10:38:49 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Apr 2019 10:38:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyTouNkvFLKyjTFUH7u9GVmk5T4dQK9KRnfKcTctslw=; b=GfyNzFPPoN21ev1P2OR3VZZtzTLaRiAUEEHVrKCTulIgi5duoQZ7baqbGLmGrwP+qAqNkl9KZ9esDGOg4mku1hPmKKJwEuZAJNPclAM1LtNEtbNBpFXAetQvL78DbZXRda6qR0yrHcSWdHD4BQliODMfe0bjGV6pdfLzoSSn68w= Received: from BY5PR11MB4037.namprd11.prod.outlook.com (10.255.161.210) by BY5PR11MB4021.namprd11.prod.outlook.com (10.255.161.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Mon, 29 Apr 2019 15:38:48 +0000 Received: from BY5PR11MB4037.namprd11.prod.outlook.com ([fe80::608b:c4db:ca21:b0ae]) by BY5PR11MB4037.namprd11.prod.outlook.com ([fe80::608b:c4db:ca21:b0ae%4]) with mapi id 15.20.1835.016; Mon, 29 Apr 2019 15:38:48 +0000 From: "Jan Komissar (jkomissa)" To: David Schinazi , Stuart Cheshire CC: DNSSD Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-push Thread-Index: AQHU862+HHNXiouiakCm0k7H6pvGS6ZN9jqAgARhSgCAAMFWAA== Date: Mon, 29 Apr 2019 15:38:48 +0000 Message-ID: <9C4A5433-4490-43B3-B82B-EFFD52FF5AB4@cisco.com> References: <19C8C2DA-8B57-44B2-9457-DCB395D95D62@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkomissa@cisco.com; x-originating-ip: [173.38.117.73] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68689417-a260-4c76-ae92-08d6ccb8c5e2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BY5PR11MB4021; x-ms-traffictypediagnostic: BY5PR11MB4021: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(366004)(39860400002)(376002)(199004)(189003)(76176011)(64756008)(66446008)(76116006)(66476007)(66556008)(66946007)(5024004)(236005)(6116002)(3846002)(5660300002)(26005)(14444005)(73956011)(58126008)(91956017)(316002)(110136005)(229853002)(256004)(25786009)(102836004)(99286004)(86362001)(7736002)(68736007)(53546011)(6506007)(478600001)(81156014)(81166006)(97736004)(82746002)(66066001)(4326008)(8676002)(6436002)(446003)(11346002)(476003)(2616005)(83716004)(6512007)(71200400001)(2906002)(53936002)(71190400001)(966005)(186003)(14454004)(486006)(6486002)(54896002)(6306002)(33656002)(8936002)(6246003)(36756003)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4021; H:BY5PR11MB4037.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MzmimNadmpJOMpSrMNxMq+FJzbFx1deJrIaodgx50S36QuuOl3Cwuis5Wi/FNs2ut/Xid9hi2uHZK8A/KRuYaivSsTCwXq/r0lLCZSCdviRFMEDT1G9lzA90ED2atbeJUC8eD3EjXZtXOMzoy2E2j0hizeO0esjYZw0rNr4MRj2nxpIQKhNaiJ/kNWONboo3jGnH8ez27pQgwmI6PqN1v512fiU7occ8SrpMoOiYGiAla+6QZTN5HerILRuV5IWRJKnMrv0hlGPikOs80is9sclbNxNhgEjw1fWOJFRvBTzHk4AGIw9CWljyvz2N7uk34rIYWAZiM3OOnU57VKJeJJqgRDLsZQ3fKvBMrIPo0IRjPGmngvYX8iiLf1VgWFQU696dt+nK02SjoQkGshWRHwf+d4U3AS2l/lQ/j+LhYLg= Content-Type: multipart/alternative; boundary="_000_9C4A5433449043B3B82BEFFD52FF5AB4ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 68689417-a260-4c76-ae92-08d6ccb8c5e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 15:38:48.3939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4021 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-push X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 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, 29 Apr 2019 15:38:53 -0000 --_000_9C4A5433449043B3B82BEFFD52FF5AB4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCBsb29rcyBmaW5lIHRvIG1lLg0KDQpKYW4uDQoNCkZyb206IGRuc3NkIDxkbnNz ZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6 aS5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFN1bmRheSwgQXByaWwgMjgsIDIwMTkgYXQgODowNyBQ TQ0KVG86IFN0dWFydCBDaGVzaGlyZSA8Y2hlc2hpcmU9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5v cmc+DQpDYzogRE5TU0QgPGRuc3NkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkbnNzZF0gV0dM QyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoDQoNClRoYW5rIHlvdSBTdHVhcnQuDQoNClRvIGdp dmUgd29ya2luZyBncm91cCBtZW1iZXJzIHRpbWUgdG8gcmV2aWV3IHRoaXMgZGlmZiBhbmQgeW91 ciBlbWFpbCwgd2UgYXJlIGV4dGVuZGluZyB0aGlzIFdHTEMgYnkgYSB3ZWVrLCB1bnRpbCAyMDE5 LTA1LTA2Lg0KDQpGb3IgZnV0dXJlIHJlZmVyZW5jZSwgeW91IGNhbiB1c2UgcmZjZGlmZiB3aXRo IHB1Ymxpc2hlZCBkcmFmdCBuYW1lcyBpbiB0aGUgVVJMOg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy8vcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtZG5zc2QtcHVzaC0xNiZ1cmwyPWRyYWZ0LWlldGYt ZG5zc2QtcHVzaC0xOTxodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1p ZXRmLWRuc3NkLXB1c2gtMTYmdXJsMj1kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTk+DQoNClNwZWFr aW5nIHdpdGggV0cgY2hhaXIgaGF0IG9mZiwgSSBwZXJzb25hbGx5IGRvIG5vdCBzZWUgYW55IHBy b2JsZW0gd2l0aCB0aGVzZSBjaGFuZ2VzIGFuZCBzdXBwb3J0IHB1YmxpY2F0aW9uLg0KDQpUaGFu a3MsDQpEYXZpZA0KDQpPbiBUaHUsIEFwciAyNSwgMjAxOSBhdCAxMDoxMyBQTSBTdHVhcnQgQ2hl c2hpcmUgPGNoZXNoaXJlPTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFwcGxl LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KT24gMTUgQXByIDIwMTksIGF0IDEwOjA3LCBE YXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpkc2NoaW5hemku aWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBUaGlzIGVtYWlsIHN0YXJ0cyBhbm90aGVyIFdv cmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xDKSBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLCB3 aGljaCB3aWxsIGxhc3QgZm9yIHR3byB3ZWVrcyB1bnRpbCAyMDE5LTA0LTI5LiBBcyBhIHJlbWlu ZGVyLCB0aGlzIGRvY3VtZW50IGhhcyBhbHJlYWR5IHBhc3NlZCBXR0xDIGJ1dCBzb21lIHNsaWdo dCBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCB3YXJyYW50ZWQgYW5vdGhlciBXR0xDLg0KDQpUaGFu ayB5b3UgRGF2aWQuDQoNCkkgaGF2ZSBhdHRhY2hlZCBhbiBIVE1MIGZpbGUgb2YgdGhlIG91dHB1 dCBmcm9tIDxodHRwczovL3Rvb2xzLmlldGYuLm9yZy9yZmNkaWZmPGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvcmZjZGlmZj4+IGNvbXBhcmluZyBkcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTYgd2l0aCBk cmFmdC1pZXRmLWRuc3NkLXB1c2gtMTkuDQoNClRoZXJlIGFyZSBhIHZhcmlldHkgb2YgbWlub3Ig dGV4dHVhbCBjaGFuZ2VzLCBzdWNoIGFzIHJlcGxhY2luZyByZWZlcmVuY2VzIHRvIGRyYWZ0LWll dGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwgd2l0aCByZWZlcmVuY2VzIHRvIFJGQyA4NDkwLCBub3cg dGhhdCB0aGlzIGRvY3VtZW50IGlzIHB1Ymxpc2hlZC4NCg0KSW4gdGVybXMgb2Ygc3Vic3RhbnRp dmUgY2hhbmdlcywgdGhlcmUgYXJlIHR3bzoNCg0KMS4gRE5TIFB1c2ggTm90aWZpY2F0aW9uIFJF Q09ORklSTQ0KDQpXZSByZWFsaXplZCB0aGF0IHRoZXJlIGlzIG5vIHVzZWZ1bCByZXNwb25zZSB0 byBhIFJFQ09ORklSTSByZXF1ZXN0LiBXZSBjaGFuZ2VkIFJFQ09ORklSTSB0byBiZSBhIHVuaWRp cmVjdGlvbmFsIERTTyBtZXNzYWdlLCBhbmQgdGhhdCByZXN1bHRzIGluIHRoZSBkZWxldGlvbiBv ZiB0aGUgZW50aXJlIOKAnFJFQ09ORklSTSBSZXNwb25zZeKAnSBzZWN0aW9uLiBUaGlzIHNpbXBs aWZpZXMgYm90aCBjb2RlLCBhbmQgdGhlIGRvY3VtZW50Lg0KDQoyLiBETlMgUHVzaCBOb3RpZmlj YXRpb24gVXBkYXRlcw0KDQpQcmV2aW91c2x5LCBUb20gUHVzYXRlcmkgYW5kIEkgdGhvdWdodCB0 aGF0IGJvcnJvd2luZyB0aGUgRE5TIFVwZGF0ZSBlbmNvZGluZyBtYWRlIHNlbnNlLiBUaGF0IHdh cyBiZWZvcmUgRFNPIChSRkMgODQ5MCkuDQoNCldoZW4gaW1wbGVtZW50aW5nIHRoZSBjdXJyZW50 IHNwZWNpZmljYXRpb24gb2YgRE5TIFB1c2ggTm90aWZpY2F0aW9ucyBvdmVyIERTTywgVGVkIExl bW9uIGRpc2NvdmVyZWQgdGhhdCBpdCBoYXMgbm8gd2F5IHRvIGV4cHJlc3MgdGhlIEROUyBDTEFT UyBvZiBjaGFuZ2VzLg0KDQpXZSBuZWVkIHRvIGFkZHJlc3MgdGhlIHByb2JsZW0gVGVkIExlbW9u IGRpc2NvdmVyZWQsIGFuZCBub3cgdGhhdCBETlMgUHVzaCB1c2VzIERTTyBUTFYgZW5jb2Rpbmcg aW5zdGVhZCBvZiB0cmFkaXRpb25hbCBETlMgbWVzc2FnZXMsIHRoZSBpbmNlbnRpdmUgdG8gZm9s bG93IHN0cmljdGx5IHRoZSBleGlzdGluZyBETlMgVXBkYXRlIGVuY29kaW5nIGhhcyBkaXNhcHBl YXJlZC4NCg0KVG8gYWRkcmVzcyB0aGlzIGlzc3VlLCB3ZSBhZG9wdGVkIGEgbmV3LCBzaW1wbGVy LCB3YXkgb2YgZXhwcmVzc2luZyBjaGFuZ2VzLi4gSXTigJlzIGJyb2FkbHkgc2ltaWxhciwgYnV0 IHNpbXBsZXIuDQoNClBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGVzZSBjaGFuZ2VzIGFuZCBsZXQg dXMga25vdyBpZiB5b3Ugc2VlIGFueSBwcm9ibGVtcy4uDQoNCkFuZCBpZiB5b3UgKmRvbuKAmXQq IHNlZSBhbnkgcHJvYmxlbXMgd2l0aCB0aGVzZSBjaGFuZ2VzLCBwbGVhc2UgcmVzcG9uZCBzYXlp bmcgdGhhdCB0b28uDQoNClN0dWFydCBDaGVzaGlyZQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KZG5zc2QgbWFpbGluZyBsaXN0DQpkbnNzZEBpZXRm Lm9yZzxtYWlsdG86ZG5zc2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Ruc3NkDQo= --_000_9C4A5433449043B3B82BEFFD52FF5AB4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1B69A4E657DCF842BB0263FEAFFECDDE@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgZHJhZnQgbG9va3MgZmluZSB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SmFuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ZG5z c2QgJmx0O2Ruc3NkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEYXZpZCBTY2hp bmF6aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5T dW5kYXksIEFwcmlsIDI4LCAyMDE5IGF0IDg6MDcgUE08YnI+DQo8Yj5UbzogPC9iPlN0dWFydCBD aGVzaGlyZSAmbHQ7Y2hlc2hpcmU9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2M6IDwvYj5ETlNTRCAmbHQ7ZG5zc2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbZG5zc2RdIFdHTEMgZm9yIGRyYWZ0LWlldGYtZG5zc2QtcHVzaDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSBTdHVhcnQuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VG8gZ2l2ZSB3b3JraW5nIGdyb3VwIG1lbWJlcnMgdGltZSB0byByZXZpZXcgdGhp cyBkaWZmIGFuZCB5b3VyIGVtYWlsLCB3ZSBhcmUgZXh0ZW5kaW5nIHRoaXMgV0dMQyBieSBhIHdl ZWssIHVudGlsIDIwMTktMDUtMDYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZvciBmdXR1cmUgcmVmZXJlbmNlLCB5b3UgY2FuIHVzZSByZmNk aWZmIHdpdGggcHVibGlzaGVkIGRyYWZ0IG5hbWVzIGluIHRoZSBVUkw6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTYmYW1wO3Vy bDI9ZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTE5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnLy9yZmNk aWZmP3VybDE9ZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTE2JmFtcDt1cmwyPWRyYWZ0LWlldGYtZG5z c2QtcHVzaC0xOTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3BlYWtpbmcgd2l0aCBXRyBjaGFpciBoYXQgb2ZmLCBJIHBlcnNvbmFsbHkg ZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3aXRoIHRoZXNlIGNoYW5nZXMgYW5kIHN1cHBvcnQgcHVi bGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgMjUsIDIwMTkgYXQgMTA6MTMgUE0gU3R1 YXJ0IENoZXNoaXJlICZsdDtjaGVzaGlyZT08YSBocmVmPSJtYWlsdG86NDBhcHBsZS5jb21AZG1h cmMuaWV0Zi5vcmciPjQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAxNSBBcHIgMjAxOSwgYXQgMTA6MDcsIERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJtYWls dG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNjaGluYXppLmll dGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBUaGlzIGVtYWlsIHN0 YXJ0cyBhbm90aGVyIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xDKSBmb3IgZHJhZnQtaWV0 Zi1kbnNzZC1wdXNoLCB3aGljaCB3aWxsIGxhc3QgZm9yIHR3byB3ZWVrcyB1bnRpbCAyMDE5LTA0 LTI5LiBBcyBhIHJlbWluZGVyLCB0aGlzIGRvY3VtZW50IGhhcyBhbHJlYWR5IHBhc3NlZCBXR0xD IGJ1dCBzb21lIHNsaWdodCBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCB3YXJyYW50ZWQgYW5vdGhl ciBXR0xDLjxicj4NCjxicj4NClRoYW5rIHlvdSBEYXZpZC48YnI+DQo8YnI+DQpJIGhhdmUgYXR0 YWNoZWQgYW4gSFRNTCBmaWxlIG9mIHRoZSBvdXRwdXQgZnJvbSAmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p ZXRmLi5vcmcvcmZjZGlmZjwvYT4mZ3Q7IGNvbXBhcmluZyBkcmFmdC1pZXRmLWRuc3NkLXB1c2gt MTYgd2l0aCBkcmFmdC1pZXRmLWRuc3NkLXB1c2gtMTkuPGJyPg0KPGJyPg0KVGhlcmUgYXJlIGEg dmFyaWV0eSBvZiBtaW5vciB0ZXh0dWFsIGNoYW5nZXMsIHN1Y2ggYXMgcmVwbGFjaW5nIHJlZmVy ZW5jZXMgdG8gZHJhZnQtaWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbCB3aXRoIHJlZmVyZW5jZXMg dG8gUkZDIDg0OTAsIG5vdyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkLjxicj4NCjxi cj4NCkluIHRlcm1zIG9mIHN1YnN0YW50aXZlIGNoYW5nZXMsIHRoZXJlIGFyZSB0d286PGJyPg0K PGJyPg0KMS4gRE5TIFB1c2ggTm90aWZpY2F0aW9uIFJFQ09ORklSTTxicj4NCjxicj4NCldlIHJl YWxpemVkIHRoYXQgdGhlcmUgaXMgbm8gdXNlZnVsIHJlc3BvbnNlIHRvIGEgUkVDT05GSVJNIHJl cXVlc3QuIFdlIGNoYW5nZWQgUkVDT05GSVJNIHRvIGJlIGEgdW5pZGlyZWN0aW9uYWwgRFNPIG1l c3NhZ2UsIGFuZCB0aGF0IHJlc3VsdHMgaW4gdGhlIGRlbGV0aW9uIG9mIHRoZSBlbnRpcmUg4oCc UkVDT05GSVJNIFJlc3BvbnNl4oCdIHNlY3Rpb24uIFRoaXMgc2ltcGxpZmllcyBib3RoIGNvZGUs IGFuZCB0aGUgZG9jdW1lbnQuPGJyPg0KPGJyPg0KMi4gRE5TIFB1c2ggTm90aWZpY2F0aW9uIFVw ZGF0ZXM8YnI+DQo8YnI+DQpQcmV2aW91c2x5LCBUb20gUHVzYXRlcmkgYW5kIEkgdGhvdWdodCB0 aGF0IGJvcnJvd2luZyB0aGUgRE5TIFVwZGF0ZSBlbmNvZGluZyBtYWRlIHNlbnNlLiBUaGF0IHdh cyBiZWZvcmUgRFNPIChSRkMgODQ5MCkuPGJyPg0KPGJyPg0KV2hlbiBpbXBsZW1lbnRpbmcgdGhl IGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBvZiBETlMgUHVzaCBOb3RpZmljYXRpb25zIG92ZXIgRFNP LCBUZWQgTGVtb24gZGlzY292ZXJlZCB0aGF0IGl0IGhhcyBubyB3YXkgdG8gZXhwcmVzcyB0aGUg RE5TIENMQVNTIG9mIGNoYW5nZXMuPGJyPg0KPGJyPg0KV2UgbmVlZCB0byBhZGRyZXNzIHRoZSBw cm9ibGVtIFRlZCBMZW1vbiBkaXNjb3ZlcmVkLCBhbmQgbm93IHRoYXQgRE5TIFB1c2ggdXNlcyBE U08gVExWIGVuY29kaW5nIGluc3RlYWQgb2YgdHJhZGl0aW9uYWwgRE5TIG1lc3NhZ2VzLCB0aGUg aW5jZW50aXZlIHRvIGZvbGxvdyBzdHJpY3RseSB0aGUgZXhpc3RpbmcgRE5TIFVwZGF0ZSBlbmNv ZGluZyBoYXMgZGlzYXBwZWFyZWQuPGJyPg0KPGJyPg0KVG8gYWRkcmVzcyB0aGlzIGlzc3VlLCB3 ZSBhZG9wdGVkIGEgbmV3LCBzaW1wbGVyLCB3YXkgb2YgZXhwcmVzc2luZyBjaGFuZ2VzLi4gSXTi gJlzIGJyb2FkbHkgc2ltaWxhciwgYnV0IHNpbXBsZXIuPGJyPg0KPGJyPg0KUGxlYXNlIHRha2Ug YSBsb29rIGF0IHRoZXNlIGNoYW5nZXMgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBzZWUgYW55IHBy b2JsZW1zLi48YnI+DQo8YnI+DQpBbmQgaWYgeW91ICpkb27igJl0KiBzZWUgYW55IHByb2JsZW1z IHdpdGggdGhlc2UgY2hhbmdlcywgcGxlYXNlIHJlc3BvbmQgc2F5aW5nIHRoYXQgdG9vLjxicj4N Cjxicj4NClN0dWFydCBDaGVzaGlyZTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG5zc2QgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOmRuc3NkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG5zc2RAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbnNzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zc2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9C4A5433449043B3B82BEFFD52FF5AB4ciscocom_--