From nobody Sat Apr 2 04:53:11 2016 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 1116112D569 for ; Sat, 2 Apr 2016 04:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 IlZUJwdwHUV6 for ; Sat, 2 Apr 2016 04:53:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673F012D568 for ; Sat, 2 Apr 2016 04:53:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32Bqx8s002026 for ; Sat, 2 Apr 2016 12:52:59 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u32Bqx8s002026 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1459597980; bh=5wTOi2lRGTGRJtusyIQn/ZBQt3M=; h=From:Subject:Date:To:Mime-Version:References; b=3OJFMulJJkj5TDYBNdasmGnG7R3c84tneyjesPN5hdnMIoUosGk6dN5QF4dgzYYKs aSEVgiPdRJD7VAJaqYLvb+aBNl1/WJs0IpjXaolhNzvFx4tZ/C8Jr0+rhfw5nIduZN ER49bm1Gxj258F0bMQKkSXAG/oq3f/Y9THy5AdXs= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s31Cqx1913605718Ov ret-id none; Sat, 02 Apr 2016 12:52:59 +0100 Received: from [192.168.0.16] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32BqqFM013164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Apr 2016 12:52:53 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_B63552B5-69F8-423F-9D57-72FA7E42C0C6" Message-ID: Date: Sat, 2 Apr 2016 12:52:52 +0100 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s31Cqx191360571800; tid=s31Cqx1913605718Ov; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <5C777A33-0B5B-4B67-9D47-7ADB15716784@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u32Bqx8s002026 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: [dnssd] dnssd WG agenda X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 11:53:11 -0000 --Apple-Mail=_B63552B5-69F8-423F-9D57-72FA7E42C0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The proposed agenda for Monday is below. Any suggestions for alterations = welcome. Our main tasks are: - resolve the outcomes of WGLCs on the 'hybrid proxy' and 'label = interop=E2=80=99 drafts - decide whether DNS Push is ready to move to a WGLC - hear about the dnssd threats draft update and the new dnssd privacy = draft, and determine how to progress them Tim =E2=80=94 snip =E2=80=94 DNSSD WG Agenda IETF95, Buenos Aires Monday 4th April 2016 3.50pm - 5.20pm local time Chairs=E2=80=99 Introduction = Chairs, 5 mins Discussion: WGLC of Hybrid Unicast/Multicast DNS-Based Service Discovery = Stuart Cheshire, 25 mins draft-ietf-dnssd-hybrid-03 https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 = The level of feedback, either as comments or =E2=80=99it=E2=80=99s = ready=E2=80=99, has been light. Consideration of the scalability of the solution to a famous level would = be welcome. We need positive consensus to move forward. =20 Discussion: Next Steps for DNS Push Notifications = Tom Pusateri, 15 min draft-ietf-dnssd-push-06 https://tools.ietf.org/html/draft-ietf-dnssd-push-06 = Discussion: WGLC of On Interoperation of Labels between DNS and Other = Resolution Systems = Andrew Sullivan, 10 mins draft-ietf-dnssd-mdns-dns-interop-02 https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 = Again, the level of feedback, either as comments or =E2=80=99it=E2=80=99s = ready=E2=80=99, has been light. We need positive consensus to move forward here as well. Discussion: -03 version of Scalable DNS-SD (SSD) Threats = Hosnieh Rafiee, 10 mins draft-otis-dnssd-scalable-dns-sd-threats-03 https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 = There are very few changes in the latest version. Is it done? Discussion: New draft: Privacy Extensions for DNS-SD=09 = Christian Huitema, 10 mins draft-huitema-dnssd-privacy-00 https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00 = Discussion on next steps for handling dnssd security/privacy issues Which issues matter? Are they operational or are any protocol-specific = issues?=20 Should we merge the two drafts? = All, 10 mins Close, Next steps = Chairs, 5 mins --Apple-Mail=_B63552B5-69F8-423F-9D57-72FA7E42C0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

The proposed = agenda for Monday is below. Any suggestions for alterations = welcome.

Our main tasks = are:
- resolve the outcomes of WGLCs on the 'hybrid proxy' = and 'label interop=E2=80=99 drafts
- decide whether DNS = Push is ready to move to a WGLC
- hear about the = dnssd threats draft update and the new dnssd privacy draft, and = determine how to progress them

Tim

=E2=80=94 snip = =E2=80=94

DNSSD WG Agenda
IETF95, Buenos Aires
Monday 4th April = 2016
3.50pm - 5.20pm local time

Chairs=E2=80=99 Introduction
= Chairs, 5 mins

Discussion: WGLC of Hybrid Unicast/Multicast = DNS-Based Service Discovery
= Stuart Cheshire, 25 = mins
draft-ietf-dnssd-hybrid-03
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03
The = level of feedback, either as comments or =E2=80=99it=E2=80=99s ready=E2=80= =99, has been light.
Consideration of the scalability of the solution to = a famous level would be welcome.
We need positive consensus to move = forward.

 

Discussion: Next = Steps for DNS Push Notifications
= Tom Pusateri, 15 = min
draft-ietf-dnssd-push-06
https://tools.ietf.org/html/draft-ietf-dnssd-push-06=

Discussion: WGLC of On Interoperation of Labels = between DNS and Other Resolution Systems
= Andrew Sullivan, 10 = mins
draft-ietf-dnssd-mdns-dns-interop-02
https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-0= 2
Again, the level of feedback, either as comments or =E2=80=99it= =E2=80=99s ready=E2=80=99, has been light.
We need positive consensus to move = forward here as well.

Discussion: -03 = version of Scalable DNS-SD (SSD) Threats
= Hosnieh Rafiee, 10 = mins
draft-otis-dnssd-scalable-dns-sd-threats-03
There are very few changes in the latest version. Is = it done?

Discussion: New draft: Privacy = Extensions for DNS-SD
= Christian Huitema, = 10 mins
draft-huitema-dnssd-privacy-00
https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00<= /span>

Discussion on next steps for handling = dnssd security/privacy issues
Which issues matter? Are they = operational or are any protocol-specific issues? 
Should we merge = the two drafts?
= = All, 10 mins
Close, Next steps
= Chairs, 5 = mins



= --Apple-Mail=_B63552B5-69F8-423F-9D57-72FA7E42C0C6-- From nobody Sat Apr 2 05:23:14 2016 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 9040212D14B for ; Sat, 2 Apr 2016 05:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 tulZfvOtg_JL for ; Sat, 2 Apr 2016 05:23:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED9712D0BA for ; Sat, 2 Apr 2016 05:23:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32CN5xU009858 for ; Sat, 2 Apr 2016 13:23:05 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u32CN5xU009858 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1459599785; bh=ZFYZhGgW3EH6YxkDclSJAhGY2Lk=; h=From:Subject:Date:To:Mime-Version:References; b=5vmsDWHELkja49Cu+x0KC0Xmi1tzAIVUWWvI+pHU92nrjGo35O7O14fRBrRM7vwFP 0b0cFdeRkRCGoNvqaxvqrevmllcUVylG+XzaLY7FBk7uCk7YdD0rT5unBjVLjiKFyO SJQK1sv0jlUYQ7i5T5CpDCSo5ntJJGzSi3UXZZ3w= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s31DN51913606082Ag ret-id none; Sat, 02 Apr 2016 13:23:05 +0100 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:3506:f7:9c76:f8] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32CMsQo022556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Apr 2016 13:22:55 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_F4679A6C-EC19-406B-AC3F-0E072088DCE4" Message-ID: Date: Sat, 2 Apr 2016 13:22:54 +0100 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s31DN4191360608200; tid=s31DN51913606082Ag; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <320F98E7-1E17-4232-B661-428F73915DF1@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u32CN5xU009858 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: [dnssd] Seeking minutes taker and Jabber relay volunteers... X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:23:12 -0000 --Apple-Mail=_F4679A6C-EC19-406B-AC3F-0E072088DCE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Any volunteers for taking minutes or acting as jabber relay in the dnssd = session on Monday are very welcome. We need one of each to be able to = proceed.=20 We don=E2=80=99t expect detailed notes on everything said for the = minutes, rather a capture of the key issues and points made, and agreed = outcomes. And there=E2=80=99s now even an RFC describing the jabber = function - see https://tools.ietf.org/html/rfc7649 = . Many thanks Tim and Ralph --Apple-Mail=_F4679A6C-EC19-406B-AC3F-0E072088DCE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Any = volunteers for taking minutes or acting as jabber relay in the dnssd = session on Monday are very welcome. We need one of each to be able to = proceed. 

We don=E2=80=99t expect detailed notes on everything said for = the minutes, rather a capture of the key issues and points made, and = agreed outcomes. And there=E2=80=99s now even an RFC describing the = jabber function - see https://tools.ietf.org/html/rfc7649.

Many thanks
Tim and Ralph



= --Apple-Mail=_F4679A6C-EC19-406B-AC3F-0E072088DCE4-- From nobody Sat Apr 2 05:25:13 2016 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 F180C12D1C0 for ; Sat, 2 Apr 2016 05:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 0TWpm09roYMV for ; Sat, 2 Apr 2016 05:25:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A5F12D188 for ; Sat, 2 Apr 2016 05:25:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32CP5Vu010406 for ; Sat, 2 Apr 2016 13:25:05 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u32CP5Vu010406 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1459599905; bh=aOqrRLOqlZIDwv5sZqClQ37AeWM=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=ovpQvPTuO+Qm7Tl2BzknVcmXiuX433FFU9ZhpyCuVKlB6xlRgEfjDQmyjbaod0zjl Qet+zH1yQuIdJ98Z18+zQWaj/o1GEUtL9wXFNfP/WDA5pZIyw5SzwadJN3GtPtX1Qo 1Ps7YPfha97gsIxCTDFjIFleVLOVg2XgIkY4rpQY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s31DP519136060955k ret-id none; Sat, 02 Apr 2016 13:25:05 +0100 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:3506:f7:9c76:f8] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32COr0Y022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Apr 2016 13:24:54 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_2EA85F02-EE79-4AD8-B881-F08E98A56CFB" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Sat, 2 Apr 2016 13:24:45 +0100 References: <1C777AF5-0406-44A2-B2BC-30673E8B5ADB@ecs.soton.ac.uk> To: dnssd@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s31DP5191360609500; tid=s31DP519136060955k; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u32CP5Vu010406 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:25:12 -0000 --Apple-Mail=_2EA85F02-EE79-4AD8-B881-F08E98A56CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ralph and I will take further comments to the list in advance of the = dnssd meeting on Monday. Comments of the form =E2=80=98this is ready to ship=E2=80=99 are also = very useful. Tim > On 17 Mar 2016, at 22:39, Tim Chown wrote: >=20 > Dear dnssd WG participants, >=20 > We are initiating a WG Last Call today on = draft-ietf-dnssd-mdns-dns-interop-02, as can be found at = https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 = . >=20 > The call runs for two weeks, and will thus close on Thursday 31st = March. >=20 > Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org = list. This draft will not be advanced for = publication unless there is sufficient response and support from the WG. = And, of course, any substantive comments on the draft are strongly = encouraged as well.=20 >=20 > We will discuss the comments arising from the WGLC in the WG meeting = in BA on Monday 4th April. >=20 > Abstract >=20 > Despite its name, DNS-Based Service Discovery can use naming = systems > other than the Domain Name System when looking for services. > Moreover, when it uses the DNS, DNS-Based Service Discovery uses = the > full capability of DNS, rather than using a subset of available > octets. In order for DNS-SD to be used effectively in environments > where multiple different name systems and conventions for their > operation are in use, it is important to attend to differences in = the > underlying technology and operational environment. This memo > presents an outline of the requirements for selection of labels for > conventional DNS and other resolution systems when they are = expected > to interoperate in this manner. >=20 >=20 > Thanks, >=20 > Ralph and Tim > dnssd WG co-chairs >=20 >=20 >=20 --Apple-Mail=_2EA85F02-EE79-4AD8-B881-F08E98A56CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Ralph = and I will take further comments to the list in advance of the dnssd = meeting on Monday.

Comments of the form =E2=80=98this is ready to ship=E2=80=99 = are also very useful.

=
Tim

On 17 Mar 2016, at 22:39, Tim Chown <tjc@ecs.soton.ac.uk>= wrote:

Dear dnssd WG = participants,

We are = initiating a WG Last Call today on draft-ietf-dnssd-mdns-dns-interop-02, = as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-0= 2.

The call runs for two weeks, and will thus close on Thursday = 31st March.

Please send any comments (including indications of support = for progression of the document as is) to the dnssd@ietf.org list. This = draft will not be advanced for publication unless there is = sufficient response and support from the WG.  And, of course, = any substantive comments on the draft are strongly encouraged as = well. 

We = will discuss the comments arising from the WGLC in the WG meeting in BA = on Monday 4th April.

Abstract

   Despite its name, DNS-Based Service Discovery can use naming systems
   other than the Domain Name System when looking for services.
   Moreover, when it uses the DNS, DNS-Based Service Discovery uses the
   full capability of DNS, rather than using a subset of available
   octets.  In order for DNS-SD to be used effectively in environments
   where multiple different name systems and conventions for their
   operation are in use, it is important to attend to differences in the
   underlying technology and operational environment.  This memo
   presents an outline of the requirements for selection of labels for
   conventional DNS and other resolution systems when they are expected
   to interoperate in this manner.


Thanks,

Ralph and Tim
dnssd WG = co-chairs




= --Apple-Mail=_2EA85F02-EE79-4AD8-B881-F08E98A56CFB-- From nobody Sat Apr 2 05:25:26 2016 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 88B5512D77C for ; Sat, 2 Apr 2016 05:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 QjwlXgwrFecn for ; Sat, 2 Apr 2016 05:25:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35A812D573 for ; Sat, 2 Apr 2016 05:25:21 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32CPG25010529 for ; Sat, 2 Apr 2016 13:25:16 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u32CPG25010529 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1459599916; bh=XXl6RKiE7ymg7jRZjVRwy5N+qTI=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=uC//6P/EFR1O9R33ekabUivl5eSuoWMXPjkJ80gcZdG85fUeIkTzZGVqOnGQi7Pp4 ZE3zUBm9G2AQSIu06WlnL49OLRRswJioXe90RbxD4RvGPambnkU5ci2zPuGpdLlDya E9KP8YJbys1W58GUKczUUO/ThkMhURxokszNMxOA= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s31DPG1913606098Of ret-id none; Sat, 02 Apr 2016 13:25:16 +0100 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:3506:f7:9c76:f8] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32COr0Z022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Apr 2016 13:25:09 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_EC6A401F-C51A-4C2C-9AAC-78B56631E550" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Sat, 2 Apr 2016 13:25:09 +0100 References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> To: dnssd@ietf.org In-Reply-To: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s31DPG191360609800; tid=s31DPG1913606098Of; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u32CPG25010529 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:25:24 -0000 --Apple-Mail=_EC6A401F-C51A-4C2C-9AAC-78B56631E550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ralph and I will take further comments to the list in advance of the = dnssd meeting on Monday. Comments of the form =E2=80=98this is ready to ship=E2=80=99 are also = very useful. Tim > On 17 Mar 2016, at 22:36, Tim Chown wrote: >=20 > Dear dnssd WG participants, >=20 > We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, = as can be found at = https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 = . >=20 > The call runs for two weeks, and will thus close on Thursday 31st = March. >=20 > Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org = list. This draft will not be advanced for = publication unless there is sufficient response and support from the WG. = And, of course, any substantive comments on the draft are strongly = encouraged as well. We are aware of a small number of minor outstanding = comments from the list, but will consider these as part of the WGLC = process. >=20 > We will discuss the comments arising from the WGLC in the WG meeting = in BA on Monday 4th April. >=20 > Abstract >=20 > Performing DNS-Based Service Discovery using purely link-local > Multicast DNS enables discovery of services that are on the local > link, but not (without some kind of proxy or similar special = support) > discovery of services that are outside the local link. Using a = very > large local link with thousands of hosts facilitates service > discovery, but at the cost of large amounts of multicast traffic. >=20 > Performing DNS-Based Service Discovery using purely Unicast DNS is > more efficient and doesn't require excessively large multicast > domains, but requires that the relevant data be available in the > Unicast DNS namespace. This can be achieved by manual DNS > configuration (as has been done for many years at IETF meetings to > advertise the IETF Terminal Room printer) but this is labor > intensive, error prone, and requires a reasonable degree of DNS > expertise. The Unicast DNS namespace can be populated with the > required data automatically by the devices themselves, but that > requires configuration of DNS Update keys on the devices offering = the > services, which has proven onerous and impractical for simple = devices > like printers and network cameras. >=20 > Hence, to facilitate efficient and reliable DNS-Based Service > Discovery, a compromise is needed that combines the ease-of-use of > Multicast DNS with the efficiency and scalability of Unicast DNS. >=20 >=20 > Thanks, >=20 > Ralph and Tim > dnssd WG co-chairs >=20 >=20 >=20 >=20 --Apple-Mail=_EC6A401F-C51A-4C2C-9AAC-78B56631E550 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Ralph = and I will take further comments to the list in advance of the dnssd = meeting on Monday.

Comments of the form =E2=80=98this is ready to ship=E2=80=99 = are also very useful.

Tim


On 17 Mar 2016, at 22:36, Tim Chown <tjc@ecs.soton.ac.uk>= wrote:

Dear dnssd WG = participants,

We are = initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as = can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03.

The = call runs for two weeks, and will thus close on Thursday 31st = March.

Please = send any comments (including indications of support for progression of = the document as is) to the dnssd@ietf.org list. This draft will not be advanced = for publication unless there is sufficient response and support = from the WG.  And, of course, any substantive comments on the = draft are strongly encouraged as well. We are aware of a small = number of minor outstanding comments from the list, but will consider = these as part of the WGLC process.

We will discuss the comments arising = from the WGLC in the WG meeting in BA on Monday 4th April.

Abstract

   Performing DNS-Based Service Discovery using purely link-local
   Multicast DNS enables discovery of services that are on the local
   link, but not (without some kind of proxy or similar special support)
   discovery of services that are outside the local link.  Using a very
   large local link with thousands of hosts facilitates service
   discovery, but at the cost of large amounts of multicast traffic.

   Performing DNS-Based Service Discovery using purely Unicast DNS is
   more efficient and doesn't require excessively large multicast
   domains, but requires that the relevant data be available in the
   Unicast DNS namespace.  This can be achieved by manual DNS
   configuration (as has been done for many years at IETF meetings to
   advertise the IETF Terminal Room printer) but this is labor
   intensive, error prone, and requires a reasonable degree of DNS
   expertise.  The Unicast DNS namespace can be populated with the
   required data automatically by the devices themselves, but that
   requires configuration of DNS Update keys on the devices offering the
   services, which has proven onerous and impractical for simple devices
   like printers and network cameras.

   Hence, to facilitate efficient and reliable DNS-Based Service
   Discovery, a compromise is needed that combines the ease-of-use of
   Multicast DNS with the efficiency and scalability of Unicast =
DNS.


Thanks,

Ralph and Tim
dnssd WG co-chairs





= --Apple-Mail=_EC6A401F-C51A-4C2C-9AAC-78B56631E550-- From nobody Sat Apr 2 08:18:04 2016 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 1EDC112D586 for ; Sat, 2 Apr 2016 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBWnqO5PAvRN for ; Sat, 2 Apr 2016 08:18:01 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 7A18512D584 for ; Sat, 2 Apr 2016 08:18:01 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5956425CA258 for ; Sat, 2 Apr 2016 15:17:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BDXb7KCQR02 for ; Sat, 2 Apr 2016 17:17:26 +0200 (CEST) Received: from localhost.localdomain (p200300864F392B6EF2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f39:2b6e:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id B798C25CA051 for ; Sat, 2 Apr 2016 17:17:26 +0200 (CEST) To: dnssd@ietf.org From: Hosnieh Rafiee Message-ID: <56FFE286.9010304@rozanak.com> Date: Sat, 2 Apr 2016 17:17:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030004040207040605070705" Archived-At: Subject: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 15:18:03 -0000 This is a multi-part message in MIME format. --------------030004040207040605070705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, Would you please take a look on the latest version of threat model https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 Please let me know what else you want to see in the draft or whether the current version address the concerns mentioned in the last IETF (minutes here : https://www.ietf.org/proceedings/94/minutes/minutes-94-dnssd ) Thanks, Best, Hosnieh --------------030004040207040605070705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Folks,

Would you please take a look on the latest version of threat model
https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03

Please let me know what else you want to see in the draft or whether the current version address the concerns mentioned in the last IETF
(minutes here : https://www.ietf.org/proceedings/94/minutes/minutes-94-dnssd )

Thanks,
Best,
Hosnieh

 --------------030004040207040605070705-- From nobody Sat Apr 2 10:47:51 2016 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 735A112D177 for ; Sat, 2 Apr 2016 10:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFwPG0gk7G61 for ; Sat, 2 Apr 2016 10:47:47 -0700 (PDT) Received: from johanna4.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73C12D0F2 for ; Sat, 2 Apr 2016 10:47:47 -0700 (PDT) RazorGate-KAS: Status: not_detected RazorGate-KAS: Rate: 0 RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 215 2015-05-29_17-31-22 60ae4a1b4d01d14f868b20a55aced8d7df7b2e28 RazorGate-KAS: Lua profiles 78662 [Jun 02 2015] RazorGate-KAS: Method: none Received: from poro.lan (80.220.86.47) by johanna4.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E91EA2015FBE13; Sat, 2 Apr 2016 20:47:44 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Markus Stenberg In-Reply-To: Date: Sat, 2 Apr 2016 20:47:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <86F10293-5C6E-447E-B14A-0C41354D4439@iki.fi> References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> To: Chown Tim X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 17:47:50 -0000 I was on vacation during WGLC (good timing - I was leaving home when it = started, lost my laptop charger early on the trip and by the time I got = home official WGLC window was done). Disclaimer: This is a beer-powered = remotely participating hobbyist commentary based on reading my own = earlier comments + draft deltas, and does not consititute a full review. = Sorry. Anyway.. Section 1 - isn=E2=80=99t this scheme essentially aiming at causing more = multicast duplication too? (e.g. given =E2=80=98home=E2=80=99 DNS-SD = browse domain, if we send unicast for each sublink.home, we wind up with = N multicasts per single logical request). Section 4.5.1 - I wonder about positive TTL limiting. Because if device = =E2=80=98moves=E2=80=99, it most likely will either a) have two different names (foo.link1.home, foo.link2.home), or b) one name with two addresses (foo.link1.home A 192.168.1.1, = foo.link1.home A 192.168.1.2). Happy Eyeballs-ish should take care of either in practise, so I am = against positive TTL limiting. Negative TTL limiting makes sense except = in some DoS scenarios which can be circumvented to some degree by e.g. = limiting total # of multicasts send by hybrid proxy over time interval = per link or something. Overall, I find the text bit too prescriptive (=E2=80=98do it this = way=E2=80=99), as it forbids you from having a service that e.g. only = supports printer and apple TV services, and proactively queries for them = rarely =3D> no need for extra traffic by whatever occurs on wire, and = the content could be even pushed to e.g. normal DNS-SD using DNS Update = or equivalent ( draft-lemon-homenet-naming-architecture-00.txt has = strawman proposal about this, and I thought about it years ago too but = never got around to implementing or specifying it ). Another scheme = would be completely passive node that did clever things with e.g. L2 = availability to detect when stuff drops off link =E2=80=98fast = enough=E2=80=99. Second major missing piece from my point of view is the section 6.4 = paragraph 2 - stitching together of zones. As it is, the single logical = request =3D> N multicasts propagation sounds somewhat undesirable to me. While not having reread the whole thing again (see sorry above), my = earlier nits are mostly addressed, I cannot find anything particularly = broken (see disclaimer about beer), and I think it is =E2=80=98ready=E2=80= =99 for some definition of ready. I would not personally want it as a = choice for any large network though, due to it forcing exactly one = operating model for the mdns->dnssd translation which I am no longer = convinced is actually optimal. For home network purposes this works, but = I would be leery of saying this is =E2=80=99the way to do it=E2=80=99 = without some simulation results in e.g. enterprise or university = deployment scenarios. Cheers, -Markus= From nobody Sat Apr 2 12:38:21 2016 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 4026412D17B for ; Sat, 2 Apr 2016 12:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ktM9H4wzO9er for ; Sat, 2 Apr 2016 12:38:17 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 CFBFE12D0DC for ; Sat, 2 Apr 2016 12:38:17 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c20so6078225pfc.1 for ; Sat, 02 Apr 2016 12:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:message-id:references:to; bh=ZaDmEQCWrXV8y4Q5VchQaXQ/3aUK6lRbAgazy9wRzoo=; b=e/AEkpim5/zgZ8VdS94igFUn3kZz4kK9bcYApEQbzFD3fwO8r1p4pLVo2JWBopiQiu 2xN/8hCscL33ytRpoKkzatS4gWwT+Fu2QhgkeXsgIpQ4wQ7qr4VNg5SrjM8OCV5uA8+M 365hdWC321hidqh9w8VybihHOND+Lm7vz9b03a086VQKJHobLOySXIiQy/xmeEu5j4NL ncSJQ2Hg9RoYnCkEo2q7QKwWLYLXtwhTAM1pgq8sWx5Fc5MExMDjvmW6tGp3TRRZyBXR axi7YjtQAPSZs284NZ+3J4E5hF3XojzgLj82gautmBng4yaiYVrt8PpTYhTaLW7y5Ts0 jp3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :message-id:references:to; bh=ZaDmEQCWrXV8y4Q5VchQaXQ/3aUK6lRbAgazy9wRzoo=; b=JC+GMCyIFJ/1yhrc6SXoabjkf9iK3vst4LlrWKem51PsIOIdJ3kVt5wx+BrEgqvL89 f4bYORYdGApHEcnczJx0B8N1miiUUr4BzJy6QpR6sRMqRmRgken68h0Ky7L2YClZrIRC +qvpY3QfwkbsuTFvRnM/mMU4CosIpavFMIGa0Ob4X5yArjUdXctKPooX8SFAfFcZf2yH tWmQhGW4awN4inVlNq9oTND9YP2CR4xkSsBYa2ZQnUkVILdcMP+JtHr6Jz5TNAtA8sBW /Jau2cbLFDxmPvzZfogzJigBt/Q6TcaZlkT3zcF98qd9hdDhNwaODaZqkDAGrWY48/mb P+tQ== X-Gm-Message-State: AD7BkJIAbJx5zAe8mmWJpwOFfEiODhHBywUxWeQIiLBOeeyOQcGC327r6o4E5dUu39+lxQ== X-Received: by 10.98.17.74 with SMTP id z71mr8280862pfi.30.1459625897409; Sat, 02 Apr 2016 12:38:17 -0700 (PDT) Received: from rtp-vpn4-1164.cisco.com ([173.38.117.78]) by smtp.gmail.com with ESMTPSA id to9sm30800635pab.27.2016.04.02.12.38.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 12:38:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C8523650-0FCF-42C3-B34B-53FCFEF24643"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Ralph Droms In-Reply-To: Date: Sat, 2 Apr 2016 16:38:11 -0300 Message-Id: References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> To: dnssd@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 19:38:20 -0000 --Apple-Mail=_C8523650-0FCF-42C3-B34B-53FCFEF24643 Content-Type: multipart/alternative; boundary="Apple-Mail=_5D243FCF-C779-4FEB-A385-38EA872997E9" --Apple-Mail=_5D243FCF-C779-4FEB-A385-38EA872997E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a technical issue with draft-ietf-dnssd-hybrid-03 that, in my = opinion, requires come clarification. Section 4.3 describes how a Hybrid Proxy processes a received Unicast = DNS query. I understand, in principle, that the Hybrid Proxy consults = its local mDNS cache to construct a response to the Unicast DNS Query. = The last paragraph begins with: Naturally, the existing Multicast DNS caching mechanism is used to avoid issuing unnecessary Multicast DNS queries on the wire. I've re-read section 5.2 of RFC 6762, "Multicast DNS". Based on section = 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I would = not be able to justify the specific ways in which the Hybrid Proxy cache = is used and any requirements for the Hybrid Proxy to issue an mDNS query = to refresh its cache. That is, I can't determine if the Hybrid Proxy = always issues an mDNS query based on a received Unicast DNS query to = initially populate its cache, or if the Hybrid Proxy can construct its = response based solely on its cache in some circumstances, or there is = some other behavior. - Ralph > On Mar 17, 2016, at 7:36 PM 3/17/16, Tim Chown > wrote: >=20 > Dear dnssd WG participants, >=20 > We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, = as can be found at = https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 = . >=20 > The call runs for two weeks, and will thus close on Thursday 31st = March. >=20 > Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org = list. This draft will not be advanced for = publication unless there is sufficient response and support from the WG. = And, of course, any substantive comments on the draft are strongly = encouraged as well. We are aware of a small number of minor outstanding = comments from the list, but will consider these as part of the WGLC = process. >=20 > We will discuss the comments arising from the WGLC in the WG meeting = in BA on Monday 4th April. >=20 > Abstract >=20 > Performing DNS-Based Service Discovery using purely link-local > Multicast DNS enables discovery of services that are on the local > link, but not (without some kind of proxy or similar special = support) > discovery of services that are outside the local link. Using a = very > large local link with thousands of hosts facilitates service > discovery, but at the cost of large amounts of multicast traffic. >=20 > Performing DNS-Based Service Discovery using purely Unicast DNS is > more efficient and doesn't require excessively large multicast > domains, but requires that the relevant data be available in the > Unicast DNS namespace. This can be achieved by manual DNS > configuration (as has been done for many years at IETF meetings to > advertise the IETF Terminal Room printer) but this is labor > intensive, error prone, and requires a reasonable degree of DNS > expertise. The Unicast DNS namespace can be populated with the > required data automatically by the devices themselves, but that > requires configuration of DNS Update keys on the devices offering = the > services, which has proven onerous and impractical for simple = devices > like printers and network cameras. >=20 > Hence, to facilitate efficient and reliable DNS-Based Service > Discovery, a compromise is needed that combines the ease-of-use of > Multicast DNS with the efficiency and scalability of Unicast DNS. >=20 >=20 > Thanks, >=20 > Ralph and Tim > dnssd WG co-chairs >=20 >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_5D243FCF-C779-4FEB-A385-38EA872997E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have a technical issue with draft-ietf-dnssd-hybrid-03 = that, in my opinion, requires come clarification.

Section 4.3 describes how a Hybrid = Proxy processes a received Unicast DNS query.  I understand, in = principle, that the Hybrid Proxy consults its local mDNS cache to = construct a response to the Unicast DNS Query.  The last paragraph = begins with:

   Naturally, the existing = Multicast DNS caching mechanism is used to
  =  avoid issuing unnecessary Multicast DNS queries on the = wire.

I've = re-read section 5.2 of RFC 6762, "Multicast DNS".  Based on section = 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I would = not be able to justify the specific ways in which the Hybrid Proxy cache = is used and any requirements for the Hybrid Proxy to issue an mDNS query = to refresh its cache.  That is, I can't determine if the Hybrid = Proxy always issues an mDNS query based on a received Unicast DNS query = to initially populate its cache, or if the Hybrid Proxy can construct = its response based solely on its cache in some circumstances, or there = is some other behavior.

- Ralph

On Mar = 17, 2016, at 7:36 PM 3/17/16, Tim Chown <tjc@ecs.soton.ac.uk>= wrote:

Dear dnssd WG = participants,

We are = initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as = can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03.

The = call runs for two weeks, and will thus close on Thursday 31st = March.

Please = send any comments (including indications of support for progression of = the document as is) to the dnssd@ietf.org list. This draft will not be advanced = for publication unless there is sufficient response and support = from the WG.  And, of course, any substantive comments on the = draft are strongly encouraged as well. We are aware of a small = number of minor outstanding comments from the list, but will consider = these as part of the WGLC process.

We will discuss the comments arising = from the WGLC in the WG meeting in BA on Monday 4th April.

Abstract

   Performing DNS-Based Service Discovery using purely link-local
   Multicast DNS enables discovery of services that are on the local
   link, but not (without some kind of proxy or similar special support)
   discovery of services that are outside the local link.  Using a very
   large local link with thousands of hosts facilitates service
   discovery, but at the cost of large amounts of multicast traffic.

   Performing DNS-Based Service Discovery using purely Unicast DNS is
   more efficient and doesn't require excessively large multicast
   domains, but requires that the relevant data be available in the
   Unicast DNS namespace.  This can be achieved by manual DNS
   configuration (as has been done for many years at IETF meetings to
   advertise the IETF Terminal Room printer) but this is labor
   intensive, error prone, and requires a reasonable degree of DNS
   expertise.  The Unicast DNS namespace can be populated with the
   required data automatically by the devices themselves, but that
   requires configuration of DNS Update keys on the devices offering the
   services, which has proven onerous and impractical for simple devices
   like printers and network cameras.

   Hence, to facilitate efficient and reliable DNS-Based Service
   Discovery, a compromise is needed that combines the ease-of-use of
   Multicast DNS with the efficiency and scalability of Unicast =
DNS.


Thanks,

Ralph and Tim
dnssd WG co-chairs




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

= --Apple-Mail=_5D243FCF-C779-4FEB-A385-38EA872997E9-- --Apple-Mail=_C8523650-0FCF-42C3-B34B-53FCFEF24643 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXAB+kAAoJEINeeBNmFjV5X0oP/1Zo1V0s+4N3KtrXW91+X1rH H7sz3sToTu5g28uK/FWNAfPkbEHggEncNF327RIz3ithTMX95bppI8SIZUHLacN2 mz9HaqJtdlhhaW94rNajMbYIDflt6BKMwAbYvBCYYN/1xnSInFITgbsS0pb3yvcw KJBW9ymSIu/VzXtaNOkWG4//tx4jTnWeofmtAQo4IhTADXAp4n+01Rxb/ieFvcLg L/BNug8I45fj/nNZla24WUq0WtuoIxHVAUyG3zFRur/g5Y3nHxMaDgJIghQP4hAd /XJffszUYffngp60kS0wnHY7rknsJi4OH2AMqVV9QqHWXGlUtOOhs/HRfr/FAPrI eWAMS5ehNM6RG7CyJtTW1OSdRxFX3CEQyrOX1oHinKja9tgWcKw03pcLXHfNCYF1 Hedu31ykS1CV7TsTWHYPgl4AhsBciGb7aO+NgQMmTxUp4np3hVZ2YTcvDFpO4Fdy 45N/kgHLcMgDaN8+Hhy2seaaTrXj4fU8U4bfb+atcd6HJT3tBE/bv9BFRnb3lzeD VinOtADpM+xZq0qRGla1EAXnDb4SfBPET/Pk7tMi16ObzIdmhSzD3YuZQn5EXr7I NS1WHC9taHUkxhTsh6YLfwoQ5EWpCBH0Qn3Qi0xVK8h5OOebBoksGKdsESnkil7g nNaZyMIRemapMRsLCyrp =IlIl -----END PGP SIGNATURE----- --Apple-Mail=_C8523650-0FCF-42C3-B34B-53FCFEF24643-- From nobody Sat Apr 2 13:22:40 2016 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 589A812D593 for ; Sat, 2 Apr 2016 13:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ENuqU38yPhR for ; Sat, 2 Apr 2016 13:22:35 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4CA12D55A for ; Sat, 2 Apr 2016 13:22:35 -0700 (PDT) Received: from dhcp-b1e5.meeting.ietf.org (dhcp-b1e5.meeting.ietf.org [31.133.177.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 61BB51DD58; Sat, 2 Apr 2016 16:21:02 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A23E6058-841D-4D76-A99E-F177EE044E55"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: Date: Sat, 2 Apr 2016 17:22:30 -0300 Message-Id: References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> To: Ralph Droms X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 20:22:37 -0000 --Apple-Mail=_A23E6058-841D-4D76-A99E-F177EE044E55 Content-Type: multipart/alternative; boundary="Apple-Mail=_7FCED03E-5C19-4047-9C3A-518AE67CFF50" --Apple-Mail=_7FCED03E-5C19-4047-9C3A-518AE67CFF50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this is answered in the details of section 4.6 Answer = Aggregation and it depends on if a subscription exists or not. Tom > On Apr 2, 2016, at 4:38 PM, Ralph Droms wrote: >=20 > I have a technical issue with draft-ietf-dnssd-hybrid-03 that, in my = opinion, requires come clarification. >=20 > Section 4.3 describes how a Hybrid Proxy processes a received Unicast = DNS query. I understand, in principle, that the Hybrid Proxy consults = its local mDNS cache to construct a response to the Unicast DNS Query. = The last paragraph begins with: >=20 > Naturally, the existing Multicast DNS caching mechanism is used to > avoid issuing unnecessary Multicast DNS queries on the wire. >=20 > I've re-read section 5.2 of RFC 6762, "Multicast DNS". Based on = section 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I = would not be able to justify the specific ways in which the Hybrid Proxy = cache is used and any requirements for the Hybrid Proxy to issue an mDNS = query to refresh its cache. That is, I can't determine if the Hybrid = Proxy always issues an mDNS query based on a received Unicast DNS query = to initially populate its cache, or if the Hybrid Proxy can construct = its response based solely on its cache in some circumstances, or there = is some other behavior. >=20 > - Ralph >=20 >> On Mar 17, 2016, at 7:36 PM 3/17/16, Tim Chown > wrote: >>=20 >> Dear dnssd WG participants, >>=20 >> We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, = as can be found at = https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 = . >>=20 >> The call runs for two weeks, and will thus close on Thursday 31st = March. >>=20 >> Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org = list. This draft will not be advanced for = publication unless there is sufficient response and support from the WG. = And, of course, any substantive comments on the draft are strongly = encouraged as well. We are aware of a small number of minor outstanding = comments from the list, but will consider these as part of the WGLC = process. >>=20 >> We will discuss the comments arising from the WGLC in the WG meeting = in BA on Monday 4th April. >>=20 >> Abstract >>=20 >> Performing DNS-Based Service Discovery using purely link-local >> Multicast DNS enables discovery of services that are on the local >> link, but not (without some kind of proxy or similar special = support) >> discovery of services that are outside the local link. Using a = very >> large local link with thousands of hosts facilitates service >> discovery, but at the cost of large amounts of multicast traffic. >>=20 >> Performing DNS-Based Service Discovery using purely Unicast DNS is >> more efficient and doesn't require excessively large multicast >> domains, but requires that the relevant data be available in the >> Unicast DNS namespace. This can be achieved by manual DNS >> configuration (as has been done for many years at IETF meetings to >> advertise the IETF Terminal Room printer) but this is labor >> intensive, error prone, and requires a reasonable degree of DNS >> expertise. The Unicast DNS namespace can be populated with the >> required data automatically by the devices themselves, but that >> requires configuration of DNS Update keys on the devices offering = the >> services, which has proven onerous and impractical for simple = devices >> like printers and network cameras. >>=20 >> Hence, to facilitate efficient and reliable DNS-Based Service >> Discovery, a compromise is needed that combines the ease-of-use of >> Multicast DNS with the efficiency and scalability of Unicast DNS. >>=20 >>=20 >> Thanks, >>=20 >> Ralph and Tim >> dnssd WG co-chairs >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd = >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_7FCED03E-5C19-4047-9C3A-518AE67CFF50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think this is answered in the details of section 4.6 Answer = Aggregation and it depends on if a subscription exists or not.

Tom

On Apr 2, 2016, at 4:38 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:

I have a technical issue with draft-ietf-dnssd-hybrid-03 = that, in my opinion, requires come clarification.

Section 4.3 describes how a Hybrid = Proxy processes a received Unicast DNS query.  I understand, in = principle, that the Hybrid Proxy consults its local mDNS cache to = construct a response to the Unicast DNS Query.  The last paragraph = begins with:

   Naturally, the existing = Multicast DNS caching mechanism is used to
  =  avoid issuing unnecessary Multicast DNS queries on the = wire.

I've = re-read section 5.2 of RFC 6762, "Multicast DNS".  Based on section = 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I would = not be able to justify the specific ways in which the Hybrid Proxy cache = is used and any requirements for the Hybrid Proxy to issue an mDNS query = to refresh its cache.  That is, I can't determine if the Hybrid = Proxy always issues an mDNS query based on a received Unicast DNS query = to initially populate its cache, or if the Hybrid Proxy can construct = its response based solely on its cache in some circumstances, or there = is some other behavior.

- Ralph

On Mar = 17, 2016, at 7:36 PM 3/17/16, Tim Chown <tjc@ecs.soton.ac.uk>= wrote:

Dear dnssd WG = participants,

We are = initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as = can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03.

The = call runs for two weeks, and will thus close on Thursday 31st = March.

Please = send any comments (including indications of support for progression of = the document as is) to the dnssd@ietf.org list. This draft will not be advanced = for publication unless there is sufficient response and support = from the WG.  And, of course, any substantive comments on the = draft are strongly encouraged as well. We are aware of a small = number of minor outstanding comments from the list, but will consider = these as part of the WGLC process.

We will discuss the comments arising = from the WGLC in the WG meeting in BA on Monday 4th April.

Abstract

   Performing DNS-Based Service Discovery using purely link-local
   Multicast DNS enables discovery of services that are on the local
   link, but not (without some kind of proxy or similar special support)
   discovery of services that are outside the local link.  Using a very
   large local link with thousands of hosts facilitates service
   discovery, but at the cost of large amounts of multicast traffic.

   Performing DNS-Based Service Discovery using purely Unicast DNS is
   more efficient and doesn't require excessively large multicast
   domains, but requires that the relevant data be available in the
   Unicast DNS namespace.  This can be achieved by manual DNS
   configuration (as has been done for many years at IETF meetings to
   advertise the IETF Terminal Room printer) but this is labor
   intensive, error prone, and requires a reasonable degree of DNS
   expertise.  The Unicast DNS namespace can be populated with the
   required data automatically by the devices themselves, but that
   requires configuration of DNS Update keys on the devices offering the
   services, which has proven onerous and impractical for simple devices
   like printers and network cameras.

   Hence, to facilitate efficient and reliable DNS-Based Service
   Discovery, a compromise is needed that combines the ease-of-use of
   Multicast DNS with the efficiency and scalability of Unicast =
DNS.


Thanks,

Ralph and Tim
dnssd WG co-chairs




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

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

= --Apple-Mail=_7FCED03E-5C19-4047-9C3A-518AE67CFF50-- --Apple-Mail=_A23E6058-841D-4D76-A99E-F177EE044E55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXACoGAAoJEPk0GMVmUuYMcO4H/jdBtfzLVnbOLxv/BWd6khVs f1o6yHnWfzLOvso/U2//4V8BrOdnT9liEQKMwbk8qsRR5y3C43eJyNUyJ3ZLYvdK M/HNblGcsydWE4y4d4hYvO+kEGWKvRswtzhj9K/ry09wSlyOyvoJkuZHm988kacx qQZUArwzBiewYzoEnYWlmZwdDTpkTmaOXHeBJlsXIZEI8qSEPdTLAqcF5QDPD6I+ gtFFiO7w98PUDKlQLvUF7nPwvF9eCbY4UzEalC5YX6l6Dyq9AvZbGEN3lQ3XnoMC DrD+55ohYWPKHsT0M9kFW+ESrHW0mHpGwFP+0j8P4/lOchCrQ8GVKu/J+kchMOM= =Bhyw -----END PGP SIGNATURE----- --Apple-Mail=_A23E6058-841D-4D76-A99E-F177EE044E55-- From nobody Sat Apr 2 16:45:17 2016 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 A784612D5A5 for ; Sat, 2 Apr 2016 16:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmDksRKjgY4j for ; Sat, 2 Apr 2016 16:45:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C47712D59A for ; Sat, 2 Apr 2016 16:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r1chm02CcMAbrLkg7iBAA/f1DIWtyzr6yCEBqqygzhA=; b=MZD7TO5s7X7Cen+UT/tGGAA7XovsLDWnNXmUuxQ+YFoNuvE9Lsq2WpTcb0gS4nqwrWVWMI3i3a3yJJT3LR+Ks1n65ZhiLK+Ib92jAoIsP3LyZn/yQO1Wbzp6t7/J1wV21SDD4AFQQOMeYm9S19UAxqQ1msREn+DwZL+mrRM6Xkk= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sat, 2 Apr 2016 23:44:51 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.025; Sat, 2 Apr 2016 23:44:51 +0000 From: Dave Thaler To: Tim Chown , "dnssd@ietf.org" , "asullivan@dyn.com" Thread-Topic: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 Thread-Index: AQHRjNq303NCp289Sk2ooC58ijO+r593VUPw Date: Sat, 2 Apr 2016 23:44:51 +0000 Message-ID: References: <1C777AF5-0406-44A2-B2BC-30673E8B5ADB@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ecs.soton.ac.uk; dkim=none (message not signed) header.d=none;ecs.soton.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [12.130.117.210] x-ms-office365-filtering-correlation-id: 0a354f89-62ef-4623-a8ec-08d35b50c8de x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 5:vmqzepnlPlDtdlaTi2dBO2yypre5reKeM0Jeu0xfKOl9SiDf0OU0YVKNBVv5rHpPzSQO94d8s2Cr4dR36XbSAwROgilXeWfd3W1EI+9hsnlLrpmSndNS+X2umB9N0mMSkhQjXLnO6uncx6QEvnGevg==; 24:IaSR2YDc9ArPqmT9SN+ZCeqJHxoszugX52P0sCwbFLpzSyl2uC/VnBxslIY5bdjNpdUdOkJl9/dgl7jc9xdCqC+ZgF56ziHB6BqDF4wcH4k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 09007040D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(377454003)(51694002)(92566002)(3280700002)(74316001)(1096002)(1220700001)(10290500002)(586003)(3846002)(5008740100001)(6116002)(102836003)(2906002)(10400500002)(31430400001)(2501003)(5005710100001)(3660700001)(19580405001)(19580395003)(33656002)(5001770100001)(107886002)(81166005)(77096005)(2900100001)(2201001)(15975445007)(5003600100002)(11100500001)(76576001)(189998001)(106116001)(10090500001)(99286002)(50986999)(86362001)(76176999)(54356999)(230783001)(5004730100002)(66066001)(122556002)(86612001)(2950100001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2016 23:44:51.3512 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 23:45:15 -0000 SSB0aGluayB0aGUgZHJhZnQgbmVlZHMgc29tZSBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMgYmVm b3JlIGl0IGlzIHJlYWR5IHRvIHNoaXAuDQoNClNlY3Rpb24gMToNCj4gQ29udmVudGlvbmFsIHVz ZSBvZg0KPiB0aGUgRE5TIGdlbmVyYWxseSBmb2xsb3dzIHRoZSBob3N0IG5hbWUgcnVsZXMgW1JG QzA5NTJdIGZvciBsYWJlbHMgLS0NCj4gdGhlIHNvLWNhbGxlZCBMREggcnVsZSANCg0KSeKAmW0g bm90IHN1cmUgSSBhZ3JlZSB3aXRoIHRoaXMgcGhyYXNpbmcuICBTZWUgaHR0cHM6Ly93aWtpLnRv b2xzLmlldGYub3JnL2h0bWwvcmZjNjA1NSNzZWN0aW9uLTMgDQoNClBlcmhhcHMgcmVwbGFjZSBz ZW50ZW5jZSB3aXRoOg0KICAgIE1hbnkgYXBwbGljYXRpb25zIGFuZCByZXNvdXJjZSByZWNvcmQg dHlwZXMgZm9sbG93IHRoZSDigJxJbnRlcm5ldCBob3N0bmFtZSINCiAgICBzeW50YXggW1JGQzA5 NTJdIGZvciBsYWJlbHMg4oCTIHRoZSBzby1jYWxsZWQgTERIIHJ1bGUuDQoNCj4gSXQgaXMgd29y dGggbm90aW5nIHRoYXQgdGhlIExESCBydWxlIGlzIGEgY29udmVudGlvbiwNCj4gYW5kIG5vdCBh IHJ1bGUgb2YgdGhlIEROUzsgdGhpcyBpcyBtYWRlIGVudGlyZWx5IHBsYWluIGJ5IFtSRkMyMTgx XSwNCj4gc2VjdGlvbiAxMSAuDQoNClN1Z2dlc3QgYXBwZW5kaW5nDQrigJxhbmQgZGlzY3Vzc2Vk IGZ1cnRoZXIgaW4gW1JGQzYwNTVdLCBzZWN0aW9uIDMu4oCdDQoNCj4gVXNlcnMgb2YgIGFwcGxp Y2F0aW9ucyBhcmUsIG9mIGNvdXJzZSwgZnJlcXVlbnRseSB1bmNvbmNlcm5lZCB3aXRoDQo+IChu b3QgdG8gc2F5IG9ibGl2aW91cyB0bykgdGhlIG5hbWUtcmVzb2x1dGlvbiBzeXN0ZW0ocykgaW4g c2VydmljZSBhdA0KPiBhbnkgZ2l2ZW4gbW9tZW50LCBhbmQgYXJlIGluY2xpbmVkIHNpbXBseSB0 byB1c2UgdGhlIHNhbWUgZG9tYWluDQo+IG5hbWVzIGluIGRpZmZlcmVudCBjb250ZXh0cy4NCg0K U3VnZ2VzdA0Kcy9Vc2VycyBvZi9Vc2VycyBhbmQgZGV2ZWxvcGVycyBvZi8NCihmb3IgcmF0aW9u YWxlIGZvciB0aGlzIGNoYW5nZSwgc2VlIGRpc2N1c3Npb24gb2YgZmlndXJlIDIgb2YgUkZDIDYw NTUpDQoNCj4gSWYgRE5TLVNEIGlzDQo+IHRvIGJlIHVzZWQgaW4gYW4gZW52aXJvbm1lbnQgd2hl cmUgbXVsdGlwbGUgcmVzb2x1dGlvbiBzeXN0ZW1zIChzdWNoDQo+IGFzIG1ETlMgYW5kIEROUykg YXJlIHRvIGJlIHF1ZXJpZWQgZm9yIHNlcnZpY2VzLCB0aGVuIHNvbWUgcGFydHMgb2YNCj4gdGhl IGRvbWFpbiBuYW1lcyB0byBiZSBxdWVyaWVkIHdpbGwgbmVlZCB0byBiZSBjb21wYXRpYmxlIHdp dGggdGhlDQo+IHJ1bGVzIGFuZCBjb252ZW50aW9ucyBmb3IgYWxsICB0aGUgcmVsZXZhbnQgdGVj aG5vbG9naWVzLg0KDQpJIGRvbuKAmXQgZm9sbG93LiAgIFRoZSBwb2ludCBvZiBSRkMgNjA1NSBp cyB0aGF0IHRoZSBlbmNvZGluZyBzaG91bGQgYmUNCmhhbmRsZWQgYnkgdGhlIG5hbWUgcmVzb2x1 dGlvbiBwcm92aWRlciAobWFwcGluZyB0byBETlMgb3IgdG8gbUROUw0Kb3IgaG9zdHMgZmlsZSBv ciB3aGF0ZXZlciBlbHNlKSBub3QgYnkgdGhlIGFwcGxpY2F0aW9uLiAgIFNvIHdoaWNoIGxheWVy DQppcyB0aGlzIHRhbGtpbmcgYWJvdXQ/DQoNClNlY3Rpb24gMS4xOg0KPiBJbiBwcmFjdGljZSwg YXBwbGljYXRpb25zDQo+IHNvbWV0aW1lcyBpbnRlcmNlcHQgbGFiZWxzIHRoYXQgZG8gbm90IGNv bmZvcm0gdG8gdGhlIExESCBydWxlIGFuZA0KPiBhcHBseSBJRE5BICBhbmQgb3RoZXIgdHJhbnNm b3JtYXRpb25zLg0KDQpVbmZvcnR1bmF0ZWx5IHRoaXMgaXMgdHJ1ZSwgd2hpY2ggaXMgd2hhdCBj YXVzZXMgbWFueSBwcm9ibGVtcyB0aGF0IGxlZA0KdG8gd3JpdGluZyBSRkMgNjA1NSB0byByZWNv bW1lbmQgdGhhdCBhcHBsaWNhdGlvbnMgKGFzIG9wcG9zZWQgdG8gbmFtZQ0KcmVzb2x1dGlvbiBs aWJyYXJpZXMpIHN0b3AgZG9pbmcgc28uICAgTm8gY2hhbmdlIG5lZWRlZCBoZXJlIEkgdGhpbmss IGp1c3QNCndhbnRlZCB0byBzYXkgSSBhZ3JlZSB0aGF0J3MgYSBwcm9ibGVtLiAgOikNCg0KU2Vj dGlvbiAyOg0KPiB3aWxsIHBlcmZvcm0gdGhlIFUtbGFiZWwvQS1sYWJlbCB0cmFuc2Zvcm1hdGlv biBhdXRvbWF0aWNhbGx5LCBzYXZpbmcNCj4gYXBwbGljYXRpb25zIGZyb20gdGhlc2UgZGV0YWls cy4gIElmIHRoaXMgd2VyZSB0aGUgbWFpbiBwcm9ibGVtLA0KDQpQZXJmb3JtaW5nIHRyYW5zZm9y bWF0aW9ucyBhdXRvbWF0aWNhbGx5IGlzIG5vdCBhIHByb2JsZW0sIGl0J3MgYSBzb2x1dGlvbi4N CkkgdGhpbmsgdGhlIHByb2JsZW0geW91J3JlIHRyeWluZyB0byBwb2ludCBvdXQgaXMgaWYgdGhl eSBkbyB0aGUgdHJhbnNmb3JtYXRpb24NCmluY29ycmVjdGx5LiAgRS5nLiwgaWYgdGhleSBkbyBz byB3aXRob3V0IHRha2luZyB0aGUgcHJvdG9jb2wgb3IgdGhlIG5hbWluZw0KY29udGV4dCBpbnRv IGFjY291bnQgYXMgZGlzY3Vzc2VkIGluIFJGQyA2MDU1LiAgIE5lZWQgdG8gcmV3b3JkIHRvIGNs YXJpZnkNCndoYXQgdGhlIHByb2JsZW0gaXMgYW5kIGlzbid0Lg0KDQpTZWN0aW9uIDM6DQo+IGFu ZCB0cmFuc21pdCBsYWJlbHMgYXMgVVRGLTggaW4gdGhlIEROUyBpcyBsaWtlbHkgZWl0aGVyIHRv IGVuY291bnRlcg0KPiBwcm9ibGVtcyBvciAgcmVzdWx0IGluIHVubmVjZXNzYXJ5IHRyYWZmaWMg dG8gdGhlIHB1YmxpYyBETlMgKG9yDQoNCkdyYW1tYXI6IGVpdGhlciBpbnNlcnQg4oCcdG/igJ0g YmVmb3JlICJyZXN1bHQiLCBvciBjaGFuZ2Ug4oCcZWl0aGVyIHRv4oCdIHRvIOKAnHRvIGVpdGhl cuKAnQ0KDQo+IEluIHBhcnRpY3VsYXIsIG1hbnkgbGFiZWxzIGluIHRoZSA8RG9tYWluPiBwYXJ0 IG9mIGEgU2VydmljZQ0KPiBJbnN0YW5jZSBOYW1lIGlzICB1bmxpa2VseSB0byBiZSBmb3VuZCBp biBpdHMgVVRGLTggZm9ybSBpbiB0aGUgcHVibGljDQoNCkdyYW1tYXI6IOKAnGxhYmVscyDigKYg aXMgLi4gaXRz4oCdLiAgUGVyaGFwcyDigJxsYWJlbHMg4oCmIGFyZSAuLiAudGhlaXLigJ0/DQoN Cj4gVS1sYWJlbHMgY2Fubm90IGNvbnRhaW4gdXBwZXIgY2FzZSBsZXR0ZXJzLiAgIA0KDQpTdWdn ZXN0IGNpdGluZyBbUkZDNTg5NF0gc2VjdGlvbnMgMy4xLjMgYW5kIDQuMi4NCg0KU2VjdGlvbiA0 LjE6DQo+IFRoZSBmaXJzdCB3YXkgd291bGQgYmUgdG8gdHJlYXQgdGhpcyBwb3J0aW9uIGFzIGxp a2VseSB0byBiZQ0KPiAgIGludGVyY2VwdGVkIGJ5IHN5c3RlbS13aWRlIElETkEtYXdhcmUgcmVz b2x2ZXJzICwNCg0KV2hhdCBkbyB5b3UgbWVhbiBieSAic3lzdGVtLXdpZGUgSUROQS1hd2FyZSBy ZXNvbHZlciIgaGVyZT8NCk9uZSB1bmF3YXJlIG9mIHdoaWNoIHByb3RvY29sIHdpbGwgYmUgdXNl ZCB0byByZXNvbHZlIGFuZCBpbiB3aGljaCBuYW1pbmcgY29udGV4dD8NCkNsYXJpZnkuDQoNCj4g ICBJbnN0ZWFkLCBETlMtU0QgaW1wbGVtZW50YXRpb25zIGNhbiBpbnRlcmNlcHQgdGhlIDxJbnN0 YW5jZT4gcG9ydGlvbg0KPiAgIG9mIGEgU2VydmljZSBJbnN0YW5jZSBOYW1lIGFuZCBlbnN1cmUg dGhhdCB0aG9zZSBsYWJlbHMgYXJlIG5ldmVyDQo+ICAgaGFuZGVkIHRvIElETkEtYXdhcmUgcmVz b2x2ZXJzIHRoYXQgbWlnaHQgYXR0ZW1wdCB0byBjb252ZXJ0IHRoZXNlDQo+ICAgbGFiZWxzIGlu dG8gQS1sYWJlbHMgLiAgDQoNCkVpdGhlciBJ4oCZbSBjb25mdXNlZCAod2hpY2ggaXMgY2VydGFp bmx5IHBvc3NpYmxlLCBidXQgd291bGQgdGhlbiBpbXBseSB0aGUgZG9jdW1lbnQNCmNvdWxkIGJl IGJldHRlciB3b3JkZWQgZm9yIGR1bW1pZXMpLCBvciBuZWl0aGVyIGFwcHJvYWNoIGluIHRoaXMg ZG9jdW1lbnQgaXMNCmNvbnNpc3RlbnQgd2l0aCBSRkMgNjA1NSByZWNvbW1lbmRhdGlvbnMuDQoN ClNlY3Rpb24gNC4zOg0KPiBNb3JlIGltcG9ydGFudCwgb3BlcmF0b3JzIG9mIGludGVybmF0aW9u YWxpemVkIGRvbWFpbiBuYW1lcyB3aWxsDQo+IGZyZXF1ZW50bHkgcHVibGlzaCBzdWNoIG5hbWVz IGluIHRoZSAgRE5TIGFzIEEtbGFiZWxzDQoNCkZvciBjbGFyaXR5IGl0IHdvdWxkIGJlIGJlc3Qg dG8gYWRkIOKAnHB1YmxpY+KAnSBiZWZvcmUgIkROUyIuDQpUaGlzIHNob3VsZG7igJl0IGNoYW5n ZSB0aGUgbWVhbmluZyBzaW5jZSB0aGUgc2VudGVuY2UgYWxyZWFkeSBzYXlzIOKAnGZyZXF1ZW50 bHnigJ0gc28gaXNu4oCZdCBhbiBhYnNvbHV0ZS4NCg0KPiBETlMtU0QgaW1wbGVtZW50YXRpb25z IG91Z2h0DQo+ICAgdG8gaWRlbnRpZnkgdGhlIDxEb21haW4+IHBvcnRpb24gb2YgdGhlIFNlcnZp Y2UgSW5zdGFuY2UgTmFtZSBhbmQNCj4gICB0cmVhdCBpdCBzdWJqZWN0IHRvIElETkEyMDA4IGlu IGNhc2UgdGhlIGRvbWFpbiBpcyB0byBiZSBxdWVyaWVkIGZyb20NCj4gICB0aGUgZ2xvYmFsIERO UyAuDQoNCklmIHRoZSDigJxETlMtU0QgaW1wbGVtZW50YXRpb27igJ0gZmFsbHMgaW50byBlaXRo ZXIgdGhlIOKAnGFwcOKAnSBjYXRlZ29yeSBvciB0aGUg4oCcbmFtZSByZXNvbHV0aW9uIEFQSeKA nQ0KY2F0ZWdvcnkgb2YgZmlndXJlIDIgb2YgUkZDIDYwNTUsIHRoZW4gSSB0aGluayB0aGlzIHRl eHQgc2VlbXMgdG8gaW1wbHkgd2hhdCBJIHdvdWxkIGNvbnNpZGVyIGJhZA0KZGVzaWduIChub3Qg aG93IHdlIHdvdWxkIGltcGxlbWVudCBpdCkuICBJbnN0ZWFkIEkgdGhpbmsgdGhlIEROUywgbURO UywgZXRjIGNvbXBvbmVudHMgDQpzaG91bGQgYWxsIGRvIHRoZSBjb3JyZWN0IHRyYW5zZm9ybWF0 aW9uLiAgIEJ1dCBSRkMgNjA1NSBqdXN0IHJlY29tbWVuZHMgdGhhdCBpdCBiZSBkb25lIGJ5IA0K c29tZSBsYXllciB0aGF0IGtub3dzIGJvdGggdGhlIHByb3RvY29sICYgdGhlIG5hbWluZyBjb250 ZXh0LCB3aGljaCBjb3VsZCBiZSB0aGUgcHJvdG9jb2wgbGF5ZXINCm9yIGNvdWxkIGJlIHRoZSBu YW1pbmcgQVBJIGxheWVyLCBidXQgdG8gbWUgaGF2aW5nIHRvIGNoYW5nZSB0aGUgbmFtaW5nIEFQ SSBsYXllciB0byBiZSBwcm90b2NvbC1hd2FyZQ0Kc2VlbXMgYXJjaGl0ZWN0dXJhbGx5IGJhZC4g ICBTbyBJIHRoaW5rIHRoZSBjb25mdXNpbmcgaXMgcGVyaGFwcyBhcm91bmQgdGhlIHRlcm0gDQri gJxETlMtU0QgaW1wbGVtZW50YXRpb25z4oCdIHdoaWNoIGNvdWxkIHVzZSBzb21lIGVsYWJvcmF0 aW9uLCBvciBhdCBsZWFzdCByZXdvcmRpbmcgZm9yIGNvbnNpc3RlbmN5DQp3aXRoIFJGQyA2MDU1 Lg0KDQpEYXZlDQoNCkZyb206IGRuc3NkIFttYWlsdG86ZG5zc2QtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFRpbSBDaG93bg0KU2VudDogU2F0dXJkYXksIEFwcmlsIDIsIDIwMTYgNToy NSBBTQ0KVG86IGRuc3NkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBXR0xDIG9uIGRy YWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMg0KDQpIaSwNCg0KUmFscGggYW5kIEkg d2lsbCB0YWtlIGZ1cnRoZXIgY29tbWVudHMgdG8gdGhlIGxpc3QgaW4gYWR2YW5jZSBvZiB0aGUg ZG5zc2QgbWVldGluZyBvbiBNb25kYXkuDQoNCkNvbW1lbnRzIG9mIHRoZSBmb3JtIOKAmHRoaXMg aXMgcmVhZHkgdG8gc2hpcOKAmSBhcmUgYWxzbyB2ZXJ5IHVzZWZ1bC4NCg0KVGltDQoNCk9uIDE3 IE1hciAyMDE2LCBhdCAyMjozOSwgVGltIENob3duIDx0amNAZWNzLnNvdG9uLmFjLnVrPiB3cm90 ZToNCg0KRGVhciBkbnNzZCBXRyBwYXJ0aWNpcGFudHMsDQpXZSBhcmUgaW5pdGlhdGluZyBhIFdH IExhc3QgQ2FsbCB0b2RheSBvbiBkcmFmdC1pZXRmLWRuc3NkLW1kbnMtZG5zLWludGVyb3AtMDIs IGFzIGNhbiBiZSBmb3VuZCBhdMKgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMi4NCg0KVGhlIGNhbGwgcnVucyBmb3IgdHdvIHdl ZWtzLCBhbmQgd2lsbCB0aHVzIGNsb3NlIG9uIFRodXJzZGF5IDMxc3QgTWFyY2guDQoNClBsZWFz ZSBzZW5kIGFueSBjb21tZW50cyAoaW5jbHVkaW5nIGluZGljYXRpb25zIG9mIHN1cHBvcnQgZm9y IHByb2dyZXNzaW9uIG9mIHRoZSBkb2N1bWVudCBhcyBpcykgdG8gdGhlwqBkbnNzZEBpZXRmLm9y ZyBsaXN0LiBUaGlzIGRyYWZ0IHdpbGwgbm90IGJlwqBhZHZhbmNlZCBmb3IgcHVibGljYXRpb24g dW5sZXNzIHRoZXJlIGlzIHN1ZmZpY2llbnQgcmVzcG9uc2UgYW5kIHN1cHBvcnQgZnJvbcKgdGhl IFdHLsKgIEFuZCwgb2YgY291cnNlLCBhbnkgc3Vic3RhbnRpdmUgY29tbWVudHMgb24gdGhlIGRy YWZ0IGFyZSBzdHJvbmdsecKgZW5jb3VyYWdlZCBhcyB3ZWxsLsKgDQoNCldlIHdpbGwgZGlzY3Vz cyB0aGUgY29tbWVudHMgYXJpc2luZyBmcm9tIHRoZSBXR0xDIGluIHRoZSBXRyBtZWV0aW5nIGlu IEJBIG9uIE1vbmRheSA0dGggQXByaWwuDQoNCkFic3RyYWN0DQoNCiAgIERlc3BpdGUgaXRzIG5h bWUsIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSBjYW4gdXNlIG5hbWluZyBzeXN0ZW1zDQog ICBvdGhlciB0aGFuIHRoZSBEb21haW4gTmFtZSBTeXN0ZW0gd2hlbiBsb29raW5nIGZvciBzZXJ2 aWNlcy4NCiAgIE1vcmVvdmVyLCB3aGVuIGl0IHVzZXMgdGhlIEROUywgRE5TLUJhc2VkIFNlcnZp Y2UgRGlzY292ZXJ5IHVzZXMgdGhlDQogICBmdWxsIGNhcGFiaWxpdHkgb2YgRE5TLCByYXRoZXIg dGhhbiB1c2luZyBhIHN1YnNldCBvZiBhdmFpbGFibGUNCiAgIG9jdGV0cy4gIEluIG9yZGVyIGZv ciBETlMtU0QgdG8gYmUgdXNlZCBlZmZlY3RpdmVseSBpbiBlbnZpcm9ubWVudHMNCiAgIHdoZXJl IG11bHRpcGxlIGRpZmZlcmVudCBuYW1lIHN5c3RlbXMgYW5kIGNvbnZlbnRpb25zIGZvciB0aGVp cg0KICAgb3BlcmF0aW9uIGFyZSBpbiB1c2UsIGl0IGlzIGltcG9ydGFudCB0byBhdHRlbmQgdG8g ZGlmZmVyZW5jZXMgaW4gdGhlDQogICB1bmRlcmx5aW5nIHRlY2hub2xvZ3kgYW5kIG9wZXJhdGlv bmFsIGVudmlyb25tZW50LiAgVGhpcyBtZW1vDQogICBwcmVzZW50cyBhbiBvdXRsaW5lIG9mIHRo ZSByZXF1aXJlbWVudHMgZm9yIHNlbGVjdGlvbiBvZiBsYWJlbHMgZm9yDQogICBjb252ZW50aW9u YWwgRE5TIGFuZCBvdGhlciByZXNvbHV0aW9uIHN5c3RlbXMgd2hlbiB0aGV5IGFyZSBleHBlY3Rl ZA0KICAgdG8gaW50ZXJvcGVyYXRlIGluIHRoaXMgbWFubmVyLg0KDQoNClRoYW5rcywNCg0KUmFs cGggYW5kIFRpbQ0KZG5zc2QgV0cgY28tY2hhaXJzDQoNCg0KDQoNCg== From nobody Sat Apr 2 18:02:58 2016 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 8017F12D12F for ; Sat, 2 Apr 2016 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_l724Rt0ufy for ; Sat, 2 Apr 2016 18:02:53 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB6712D11A for ; Sat, 2 Apr 2016 18:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 1013D10B0A for ; Sun, 3 Apr 2016 01:02:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kit4_QqscsJm for ; Sun, 3 Apr 2016 01:02:52 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2001:67c:370:136:7808:fd57:2be5:760f]) by mx2.yitter.info (Postfix) with ESMTPSA id D374D10AE8 for ; Sun, 3 Apr 2016 01:02:51 +0000 (UTC) Date: Sat, 2 Apr 2016 21:02:46 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160403010246.GR30146@mx2.yitter.info> References: <1C777AF5-0406-44A2-B2BC-30673E8B5ADB@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 01:02:55 -0000 Hi, First, thanks very much for the review. [ObIHopeObvious: I elided things I just think are good. Thanks for them.] On Sat, Apr 02, 2016 at 11:44:51PM +0000, Dave Thaler wrote: > > If DNS-SD is > > to be used in an environment where multiple resolution systems (such > > as mDNS and DNS) are to be queried for services, then some parts of > > the domain names to be queried will need to be compatible with the > > rules and conventions for all the relevant technologies. > > I don’t follow. The point of RFC 6055 is that the encoding should be > handled by the name resolution provider (mapping to DNS or to mDNS > or hosts file or whatever else) not by the application. So which layer > is this talking about? I think I don't follow. The point is that, when someone is offering services across multiple resolution contexts, there are multiple resolition systems. There's actually no way for the name resolution provider to provide the solution here, because it's impossible to know in advance which kind of provision is likely to happen. Hmm. I suppose the point is made clearer if the draft says something like, "If you are sure that nothing will go past some context -- where that context is either the LAN, or the site-network however defined -- then local conventions prevail. Otherwise, parts of the domain names to be queried 
 &c." Is that clearer? > Section 4.1: > > The first way would be to treat this portion as likely to be > > intercepted by system-wide IDNA-aware resolvers , > > What do you mean by "system-wide IDNA-aware resolver" here? > One unaware of which protocol will be used to resolve and in which naming context? > Clarify. > > Instead, DNS-SD implementations can intercept the portion > > of a Service Instance Name and ensure that those labels are never > > handed to IDNA-aware resolvers that might attempt to convert these > > labels into A-labels . > > Either I’m confused (which is certainly possible, but would then imply the document > could be better worded for dummies), or neither approach in this document is > consistent with RFC 6055 recommendations. Stuart has asserted strogly -- and I confess I have some sympathy for his claim -- that all the use cases involve pick-lists. If that's true, then the "first way" is never going to happen, and the "second way" is the only real option. And you're right that neither is actually consistent with 6055. > should all do the correct transformation. But RFC 6055 just recommends that it be done by > some layer that knows both the protocol & the naming context, which could be the protocol layer > or could be the naming API layer, but to me having to change the naming API layer to be protocol-aware > seems architecturally bad. So I think the confusing is perhaps around the term > “DNS-SD implementations” which could use some elaboration, or at least rewording for consistency > with RFC 6055. I wish I knew what the WG wanted here. I'm way more than amenable to text. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Apr 3 08:51:43 2016 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 11B0112D53D for ; Sun, 3 Apr 2016 08:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.793 X-Spam-Level: X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSOhzbwTSNYT for ; Sun, 3 Apr 2016 08:51:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C677A12D55B for ; Sun, 3 Apr 2016 08:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yLsShjgHZrW3k4RTSb6TWScrzsE5nZaT2isTkKfzuZk=; b=f2P3cQQChqMoNKo4L0ePtgGQ5jQqbEBhnREwtUe40ks5ArUZKNX1At2qHRHZsLfose7D1PRxUlYHugsQstBYBcu/pVxeZK4ViNIoPFYLE3cJaq7lKHjdlBG5bRUjh4Zadh2nllmxYHnlNlUU5yRrRoGZZp7jImTEJBb9u209Wt4= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 3 Apr 2016 15:51:38 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.025; Sun, 3 Apr 2016 15:51:39 +0000 From: Dave Thaler To: Tim Chown , "dnssd@ietf.org" , "Stuart Cheshire" Thread-Topic: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 Thread-Index: AQHRgJ2Rr53y89iVQE6o15py6Yebnp930EtQ Date: Sun, 3 Apr 2016 15:51:38 +0000 Message-ID: References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ecs.soton.ac.uk; dkim=none (message not signed) header.d=none;ecs.soton.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:160:cc7:2a0c:2c4e:fa21] x-ms-office365-filtering-correlation-id: 728890f3-0369-4c9d-b5a5-08d35bd7d813 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 5:LampQoca139HlmoDEsk4YXVKAwhlbDu9CF20m23xHR9A2wleo2XbvX37zaA/TynjVrehpkSNzpEww9KoO4I5LieiUSSh/Po5cSEboRqCFOhM7u/fNvhYYRZZN5QFk30rcvgCE/NjjLOPLox54ef6/A==; 24:ZkqQqllDHFWWBDLg0NPxygX4wGfCDu/Yi8xfceSb9l0buncEwy6C4smbJct1ISh2/E3W21LLk3HvA9wmWhkjEbLk0e0s/wDy5BB8fsqeKpk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 09011458FC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(92566002)(3280700002)(74316001)(1096002)(1220700001)(10290500002)(586003)(5008740100001)(6116002)(102836003)(2906002)(10400500002)(2501003)(5005710100001)(3660700001)(8990500004)(19580405001)(19580395003)(33656002)(5001770100001)(107886002)(81166005)(77096005)(2900100001)(15975445007)(87936001)(5003600100002)(76576001)(189998001)(106116001)(10090500001)(99286002)(50986999)(86362001)(76176999)(54356999)(230783001)(5004730100002)(122556002)(86612001)(2950100001)(5002640100001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2016 15:51:38.8919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 15:51:43 -0000 My comments... Section 1: > up the dot-local host names of peers on the same home network, and s/dot-local/".local"/ for consistency with ".home" in quotes later in the same section Section 3: > Existing clients that support DNS-Based Service Discovery over > Unicast DNS (Mac OS X 10.4 and later, including iPhone, iPad, and > Bonjour for Windows ) work with Hybrid Proxy. Suggest removing parenthetical clause since this is not a complete list. E.g., Windows 10 supports DNS-SD over unicast DNS. Rather than=20 trying to have a complete list which might be obsolete by the time the RFC is published, it's easier to omit. Section 4.2.2: > for the following Multicast DNS Domain Enumeration queries issues by s/issues/issued/ Section 4.4: > In other words, the Hybrid Proxy becomes the=20 > authoritative name server for the reverse mapping domain. This says "the" (singular) authoritative server. Is it limited to only one per link? What if it goes down? Section 4.5: > Generating the appropriate Multicast DNS queries involves, at the > very least, translating from the configured DNS domain > (e.g., "Building 1.example.com") on the Unicast DNS side to "local" > on the Multicast DNS side. > > Generating the appropriate Unicast DNS responses involves translating > back from "local" to the configured DNS Unicast domain. If the unicast query contains an xn-A-label, should the translation convert it to a U-label on the multicast side? Section 4.5.1: > reasonble to expect it to take on the order of ten seconds for a Typo "reasonble" Section 4.5.2: > Similarly, for sites that > have multiple private address realms [RFC1918], private addresses > from one private address realm should not be communicated to clients > in a different private address realm. Should "should not" be MUST NOT or SHOULD NOT? I'm guessing MUST NOT. Section 4.6: > DNS device taking even longer than that (e.g, a device that is not Missing period after "e.g" Section 5: Two notes exist that should be removed before submitting to the IESG: > [Author's note: Or maybe it could just be zero?] ... > [Author's note: Discussion of these recommendations is requested.] Section 6.1: > When you Press Cmd-P on your Mac, or > select AirPrint on your iPad or iPhone, and the Terminal room > printers appear, that is because your client is sending unicast DNS > queries to the IETF DNS servers. The use of 2nd person implies that the audience of the document is just IETF attendees. Suggest use of third-person instead. Section 8.2: > become visibile in a domain such as "My House.example.com" that might Typo " visibile " Section 8.3: > For Wi-Fi links the Multicast DNS subsystem SHOULD NOT > issue more than 20 Multicast DNS query packets per second. This does mean that an attacker that can generate >20 unicast queries (e.g.= ,=20 for names that don't exist) per second can DOS valid queries for names not in the cache. This should be pointed out since 8.3 is the section on DOS. Section 11: > [Partial list; more names to be added.] Another note to be removed before submission to IESG. Dave From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tim Chown Sent: Thursday, March 17, 2016 3:37 PM To: dnssd@ietf.org Subject: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 Dear dnssd WG participants, We are initiating a WG Last Call today on=A0draft-ietf-dnssd-hybrid-03, as = can be found at=A0https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03. The call runs for two weeks, and will thus close on Thursday 31st March. Please send any comments (including indications of support for progression = of the document as is) to the=A0dnssd@ietf.org list. This draft will not be= =A0advanced for publication unless there is sufficient response and support= from=A0the WG.=A0 And, of course, any substantive comments on the draft ar= e strongly=A0encouraged as well. We are aware of a small number of minor ou= tstanding comments from the list, but will consider these as part of the WG= LC process. We will discuss the comments arising from the WGLC in the WG meeting in BA = on Monday 4th April. Abstract Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require excessively large multicast domains, but requires that the relevant data be available in the Unicast DNS namespace. This can be achieved by manual DNS configuration (as has been done for many years at IETF meetings to advertise the IETF Terminal Room printer) but this is labor intensive, error prone, and requires a reasonable degree of DNS expertise. The Unicast DNS namespace can be populated with the required data automatically by the devices themselves, but that requires configuration of DNS Update keys on the devices offering the services, which has proven onerous and impractical for simple devices like printers and network cameras. Hence, to facilitate efficient and reliable DNS-Based Service Discovery, a compromise is needed that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. Thanks, Ralph and Tim dnssd WG co-chairs From nobody Sun Apr 3 13:18:03 2016 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 DD79B12D51B for ; Sun, 3 Apr 2016 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qaP5q8AG_ls for ; Sun, 3 Apr 2016 13:18:00 -0700 (PDT) Received: from nk11p20im-asmtp002.me.com (nk11p20im-asmtp002.me.com [17.158.216.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC8D12D161 for ; Sun, 3 Apr 2016 13:18:00 -0700 (PDT) Received: from dhcp-b1e5.meeting.ietf.org (dhcp-b1e5.meeting.ietf.org [31.133.177.229]) by nk11p20im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O5200IPOR1W3150@nk11p20im-asmtp002.me.com> for dnssd@ietf.org; Sun, 03 Apr 2016 20:17:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-03_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=13 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1604030315 From: Tom Pusateri Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Message-id: Date: Sun, 03 Apr 2016 17:17:55 -0300 To: dnssd@ietf.org MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dnssd] thoughts on WGLC for draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 20:18:02 -0000 Since Tim and Ralph asked for thoughts on draft-ietf-dnssd-hybrid-03, I = have a few comments. I have been following the versions of this draft for a few years and = have implemented most of it. Overall, I found this latest version to be = complete enough to create a reasonable implementation. I think this = alone is a good test of it=E2=80=99s completeness. I have sent comments to the list on some things I would like to see = added a few weeks ago so other than those, I think it is ready for = advancement. I think further work can be done on privacy but I don=E2=80=99t believe = this document needs to wait for this future work. Thanks, Tom From nobody Mon Apr 4 11:09:49 2016 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 A1A0412D724; Mon, 4 Apr 2016 11:09:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404180937.15606.2674.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 11:09:37 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-07.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-07.txt Pages : 33 Date : 2016-04-04 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 4 12:13:22 2016 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 914FF12D64F for ; Mon, 4 Apr 2016 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co1ms-lJnE_T for ; Mon, 4 Apr 2016 12:13:18 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id B34CA12D80C for ; Mon, 4 Apr 2016 12:13:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id EDE6910B21 for ; Mon, 4 Apr 2016 19:13:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WARlHWO0T9E for ; Mon, 4 Apr 2016 19:13:13 +0000 (UTC) Received: from anvilwalrusden.com (dhcp-b2a2.meeting.ietf.org [31.133.178.162]) by mx2.yitter.info (Postfix) with ESMTPSA id 86EA1106CC for ; Mon, 4 Apr 2016 19:13:12 +0000 (UTC) Date: Mon, 4 Apr 2016 15:13:09 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160404191306.GA36990@anvilwalrusden.com> References: <56FFE286.9010304@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FFE286.9010304@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:13:20 -0000 Hi, On Sat, Apr 02, 2016 at 05:17:26PM +0200, Hosnieh Rafiee wrote: > > Would you please take a look on the latest version of threat model > https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 I have (at last, apologies for the delay) read this version of the draft. It's with some distress I say I'm frustrated by this draft, because in my reading it treats as similar kinds of problems issues that are vastly different. At the same time, it isn't clear whether the document is just attempting to outline what the threats are, or whether it is trying to prescribe what should happen as a result. I think for it to be useful, it still needs an enormous amount of work Confusing treatment Different issues all seem to be treated as "threats" without any way of telling who is threatened, how, or how severely. For instance, the issue in 2.1.2.1 is really about user interface. There are for sure problems with this sort of visual spoofing on the Internet. Yet the entire problem of i18n and visual confusability and so on has literally nothing to do with whether you use IDNA or raw UTF-8 in the DNS, so that discussion is just a red herring. The basic problem is that users can be phished. If there is an argument here for why DNS-SD is somehow different in this than everything else on the Internet, I am unable to detect it. Moreover, the issue is mixed in to discussion in section 2.2 as well, where its relevance to exfiltration is at best unclear. The issue in 2.1.4, by contrast, is basically an argument that devices that already rely on security by obscurity need to remain obscure. I suppose that's true, but the proposed solution basically just says, "This feature that we desire shouldn't ever work." That seems to operate at an entirely different level than the i18n issues. Again, this security-by-obscurity issue reappears in 2.2, where I guess exfiltration comes up again; I think this is probably the split-horizon discussion, but it's not that clear. Yet a different kind of issue -- the side effects of amplification -- are in section 2.3. This is a generic issue with the DNS and increasing sizes of RRsets. It is undoubtedly an issue, but it's far from plain to me that the explanation here covers the way the issues play out on the Internet. The discussion in 3.2 about data integrity after publication as opposed to the correctness of the data at source is treated as an "Authorization Issue". It isn't clear that it is; and this is anyway a systemic problem with the DNS, so it isn't clear how this is a special threat case. What is the document for? In general, I find the document confusing, hard to follow, and not terribly consistent about whether it is reporting threats, or telling you what you're supposed to do in reaction. This ambiguity makes the document in some places contentious when it needn't be, since the problem described might well be accurate while the proposed solution is not one with which we'd all agree. As noted above, for instance, the very title of 2.1.4 basically undermines one of the obvious use cases for this protocol, so there's no way that everyone will accept the advice. What I would do if I wanted this document badly enough If I were the authors, I'd reorganize the draft. It seems to me there are several different kinds of threat here. One kind is threats that are inherited by virtue of the kind of system in use. So, you get the threat of someone taking over the global DNS registration for a name because you're using DNS. Another kind is threats that are not really new, but that are potentially made more easily available due to DNS-SD, such as so-called "internal" hosts that get their names more widely exposed in a split DNS scenario. Another kind is threats that are entirely new as a result of this technology. (If there are any of these in the document, I dont think I understand that.) Optionally, and only if the WG wants it, one might then have a section that lists various mitigation strategies for each of the threats. Some threats will not be mitigable when using the technology, and the only mitigation is, "Don't do that." Others might be mitigable by this or that action. I hope these remarks are useful. I'm sorry it's taken me so long to get them out. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Apr 4 12:48:11 2016 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 240A012D1CD for ; Mon, 4 Apr 2016 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ubRUg7QphmA for ; Mon, 4 Apr 2016 12:48:09 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 AFC2A12D11E for ; Mon, 4 Apr 2016 12:48:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id CC7CC25CA246; Mon, 4 Apr 2016 19:48:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJbk8IdmOXN8; Mon, 4 Apr 2016 21:47:32 +0200 (CEST) Received: from localhost.localdomain (p200300864F392BCEF2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f39:2bce:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id CD41C25CA240; Mon, 4 Apr 2016 21:47:31 +0200 (CEST) To: Andrew Sullivan , dnssd@ietf.org References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> From: Hosnieh Rafiee Message-ID: <5702C4D3.5070500@rozanak.com> Date: Mon, 4 Apr 2016 21:47:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160404191306.GA36990@anvilwalrusden.com> Content-Type: multipart/alternative; boundary="------------080402010405070700010704" Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:48:11 -0000 This is a multi-part message in MIME format. --------------080402010405070700010704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, Thanks for your comments. mine is inline. On 04/04/2016 09:13 PM, Andrew Sullivan wrote: > Hi, > > On Sat, Apr 02, 2016 at 05:17:26PM +0200, Hosnieh Rafiee wrote: >> Would you please take a look on the latest version of threat model >> https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 > I have (at last, apologies for the delay) read this version of the draft. > > It's with some distress I say I'm frustrated by this draft, because in > my reading it treats as similar kinds of problems issues that are > vastly different. At the same time, it isn't clear whether the > document is just attempting to outline what the threats are, or > whether it is trying to prescribe what should happen as a result. I > think for it to be useful, it still needs an enormous amount of work > Confusing treatment > > Different issues all seem to be treated as "threats" without any way > of telling who is threatened, how, or how severely. I am a bit confused with your sentence. I might be wrong, but usually we only specify what are the possible problems or threats but we do not care who is the attacker. we just identify the holes in the protocol but not who will use this hole to attack the system... so I am not sure what or who you wanted to see. > For instance, the issue in 2.1.2.1 is really about user interface. > There are for sure problems with this sort of visual spoofing on the > Internet. Yet the entire problem of i18n and visual confusability and > so on has literally nothing to do with whether you use IDNA or raw > UTF-8 in the DNS, so that discussion is just a red herring. The basic > problem is that users can be phished. If there is an argument here > for why DNS-SD is somehow different in this than everything else on > the Internet, I am unable to detect it. Moreover, the issue is mixed > in to discussion in section 2.2 as well, where its relevance to > exfiltration is at best unclear. 2.1.2.1 threat relates to defining a critical service when look-alike name detection becomes problematic. Unlike DNS, mDNS assumes visual selection IDNA and/or raw UTF-8 allows for many possible representations of the same visual representation. By allowing all the different representations allowed, this allows look alike names. this is why IDNA should be limited for mDNS because there might be different services with look alike names that cannot be easily determined. > The issue in 2.1.4, by contrast, is basically an argument that devices > that already rely on security by obscurity need to remain obscure. I > suppose that's true, but the proposed solution basically just says, > "This feature that we desire shouldn't ever work." That seems to > operate at an entirely different level than the i18n issues. Again, > this security-by-obscurity issue reappears in 2.2, where I guess > exfiltration comes up again; I think this is probably the > split-horizon discussion, but it's not that clear. > > Yet a different kind of issue -- the side effects of amplification -- > are in section 2.3. This is a generic issue with the DNS and > increasing sizes of RRsets. It is undoubtedly an issue, but it's far > from plain to me that the explanation here covers the way the issues > play out on the Internet. > > The discussion in 3.2 about data integrity after publication as > opposed to the correctness of the data at source is treated as an > "Authorization Issue". It isn't clear that it is; and this is anyway > a systemic problem with the DNS, so it isn't clear how this is a > special threat case. > > What is the document for? > > In general, I find the document confusing, hard to follow, and not > terribly consistent about whether it is reporting threats, or telling > you what you're supposed to do in reaction. This ambiguity makes the > document in some places contentious when it needn't be, since the > problem described might well be accurate while the proposed solution > is not one with which we'd all agree. As noted above, for instance, > the very title of 2.1.4 basically undermines one of the obvious use > cases for this protocol, so there's no way that everyone will accept > the advice. There were some sections in the draft that only focused on threats and a few sections that explains the available mechanisms that DNSSD can use to avoid such threats. But of course as you suggested and you think it is not clear what threats are new and what threats are not new, we can re-arrange the document separate these sections with different titles. > What I would do if I wanted this document badly enough > > If I were the authors, I'd reorganize the draft. It seems to me there > are several different kinds of threat here. One kind is threats that > are inherited by virtue of the kind of system in use. So, you get the > threat of someone taking over the global DNS registration for a name > because you're using DNS. Another kind is threats that are not really > new, but that are potentially made more easily available due to > DNS-SD, such as so-called "internal" hosts that get their names more > widely exposed in a split DNS scenario. Another kind is threats that > are entirely new as a result of this technology. (If there are any of > these in the document, I dont think I understand that.) > > Optionally, and only if the WG wants it, one might then have a section > that lists various mitigation strategies for each of the threats. > Some threats will not be mitigable when using the technology, and the > only mitigation is, "Don't do that." Others might be mitigable by > this or that action. > > I hope these remarks are useful. I'm sorry it's taken me so long to > get them out. > > Best regards, > > A > Best, Hosnieh --------------080402010405070700010704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Andrew,

Thanks for your comments. mine is inline.


On 04/04/2016 09:13 PM, Andrew Sullivan wrote:
Hi,

On Sat, Apr 02, 2016 at 05:17:26PM +0200, Hosnieh Rafiee wrote:

Would you please take a look on the latest version of threat model
https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03

I have (at last, apologies for the delay) read this version of the draft.

It's with some distress I say I'm frustrated by this draft, because in
my reading it treats as similar kinds of problems issues that are
vastly different.  At the same time, it isn't clear whether the
document is just attempting to outline what the threats are, or
whether it is trying to prescribe what should happen as a result.  I
think for it to be useful, it still needs an enormous amount of work


    Confusing treatment

Different issues all seem to be treated as "threats" without any way
of telling who is threatened, how, or how severely.
I am a bit confused with your sentence. I might be wrong, but usually we only specify what are the possible problems or threats but we do not care who is the attacker. we just identify the holes in the protocol but not who will use this hole to attack the system... so I am not sure what or who you wanted to see. 
For instance, the issue in 2.1.2.1 is really about user interface.
There are for sure problems with this sort of visual spoofing on the
Internet.  Yet the entire problem of i18n and visual confusability and
so on has literally nothing to do with whether you use IDNA or raw
UTF-8 in the DNS, so that discussion is just a red herring.  The basic
problem is that users can be phished.  If there is an argument here
for why DNS-SD is somehow different in this than everything else on
the Internet, I am unable to detect it.  Moreover, the issue is mixed
in to discussion in section 2.2 as well, where its relevance to
exfiltration is at best unclear.
 2.1.2.1  threat relates to defining a critical service when look-alike name detection becomes problematic.
 Unlike DNS, mDNS assumes visual selection IDNA and/or raw UTF-8 allows for many possible representations of the same visual representation.  By allowing all the different representations allowed, this allows look alike names. this is why IDNA should be limited for mDNS because there might be different services with look alike names that cannot be easily determined.
The issue in 2.1.4, by contrast, is basically an argument that devices
that already rely on security by obscurity need to remain obscure.  I
suppose that's true, but the proposed solution basically just says,
"This feature that we desire shouldn't ever work."  That seems to
operate at an entirely different level than the i18n issues.  Again,
this security-by-obscurity issue reappears in 2.2, where I guess
exfiltration comes up again; I think this is probably the
split-horizon discussion, but it's not that clear.

Yet a different kind of issue -- the side effects of amplification --
are in section 2.3.  This is a generic issue with the DNS and
increasing sizes of RRsets.  It is undoubtedly an issue, but it's far
from plain to me that the explanation here covers the way the issues
play out on the Internet.

The discussion in 3.2 about data integrity after publication as
opposed to the correctness of the data at source is treated as an
"Authorization Issue".  It isn't clear that it is; and this is anyway
a systemic problem with the DNS, so it isn't clear how this is a
special threat case.

    What is the document for?

In general, I find the document confusing, hard to follow, and not
terribly consistent about whether it is reporting threats, or telling
you what you're supposed to do in reaction.  This ambiguity makes the
document in some places contentious when it needn't be, since the
problem described might well be accurate while the proposed solution
is not one with which we'd all agree.  As noted above, for instance,
the very title of 2.1.4 basically undermines one of the obvious use
cases for this protocol, so there's no way that everyone will accept
the advice.
There were some sections in the draft that only focused on threats and a few sections that explains the available mechanisms that DNSSD can use to avoid such threats. But of course as you suggested and you think it is not clear what threats are new and what threats are not new, we can re-arrange the document separate these sections with different titles. 
    What I would do if I wanted this document badly enough

If I were the authors, I'd reorganize the draft.  It seems to me there
are several different kinds of threat here.  One kind is threats that
are inherited by virtue of the kind of system in use.  So, you get the
threat of someone taking over the global DNS registration for a name
because you're using DNS.  Another kind is threats that are not really
new, but that are potentially made more easily available due to
DNS-SD, such as so-called "internal" hosts that get their names more
widely exposed in a split DNS scenario.  Another kind is threats that
are entirely new as a result of this technology.  (If there are any of
these in the document, I dont think I understand that.)

Optionally, and only if the WG wants it, one might then have a section
that lists various mitigation strategies for each of the threats.
Some threats will not be mitigable when using the technology, and the
only mitigation is, "Don't do that."  Others might be mitigable by
this or that action.

I hope these remarks are useful.  I'm sorry it's taken me so long to
get them out.

Best regards,

A
Best,
Hosnieh
--------------080402010405070700010704-- From nobody Mon Apr 4 13:10:25 2016 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 10E6312D86F for ; Mon, 4 Apr 2016 13:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruXISQhX-5qK for ; Mon, 4 Apr 2016 13:10:21 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 41FF012D88C for ; Mon, 4 Apr 2016 13:09:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id E526B10B21 for ; Mon, 4 Apr 2016 20:09:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACuv97DQkXGq for ; Mon, 4 Apr 2016 20:09:46 +0000 (UTC) Received: from mx2.yitter.info (dhcp-b2a2.meeting.ietf.org [31.133.178.162]) by mx2.yitter.info (Postfix) with ESMTPSA id 9E6BD10AB6 for ; Mon, 4 Apr 2016 20:09:45 +0000 (UTC) Date: Mon, 4 Apr 2016 16:09:42 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160404200942.GE36990@mx2.yitter.info> References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> <5702C4D3.5070500@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5702C4D3.5070500@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:10:24 -0000 Hi, On Mon, Apr 04, 2016 at 09:47:31PM +0200, Hosnieh Rafiee wrote: > >Different issues all seem to be treated as "threats" without any way > >of telling who is threatened, how, or how severely. > I am a bit confused with your sentence. I might be wrong, but usually we > only specify what are the possible problems or threats but we do not care > who is the attacker. we just identify the holes in the protocol but not who > will use this hole to attack the system... so I am not sure what or who you > wanted to see. I'm trying to understand what the threat is from a practical point of view. For instance, there is a claim in the draft about exfiltration. The truth is that, if you're running split-horizon DNS, you _already_ have this problem. Therefore, the risk is at worst that there are more queries that contain such leaks. I don't know whether that's worse, but I confess I'm pretty sceptical; but those kinds of considerations need to be laid out. It simply isn't true that we just list the threats. We try to lay out the threats, their severity, the liklihood that they'll happen, and so on. Listing all the threats in the world would not be useful. > 2.1.2.1 threat relates to defining a critical service when look-alike name > detection becomes problematic. > Unlike DNS, mDNS assumes visual selection IDNA and/or raw UTF-8 allows for > many possible representations of the same visual representation. By > allowing all the different representations allowed, this allows look alike > names. this is why IDNA should be limited for mDNS because there might be > different services with look alike names that cannot be easily determined. I'm sorry, but this is just false. First, the problem already exists with plain LDH, because of l and 1. Second, you can trivially recreate these problems in IDNA2008 -- Latin-A and Cyrillic-A are the usual example, but there are many such cases all of which are legal in IDNA. "Look alike names" are a problem now, with the existing DNS-SD specification and with other cases (like following links). All of the rules to solve that -- using mDNS or DNS or YourNewResolutionProtocol -- need to have these things handled by policy. If the only point is, "Some policy controls are needed here," say that. But either this is no more of an issue than any other i18n issue on the Internet, or else there is something peculiar about this case that makes it more of an issue. There's been no effort AFAICT to show that the "more of an issue" case is what is going on here. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Apr 4 13:44:59 2016 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 588EE12D815 for ; Mon, 4 Apr 2016 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXZf-AAzi6Wx for ; Mon, 4 Apr 2016 13:44:56 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 35A7312D899 for ; Mon, 4 Apr 2016 13:44:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 430A325CA246; Mon, 4 Apr 2016 20:44:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4poQSclpiScl; Mon, 4 Apr 2016 22:44:17 +0200 (CEST) Received: from localhost.localdomain (p200300864F392B7AF2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f39:2b7a:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EE46F25CA240; Mon, 4 Apr 2016 22:44:16 +0200 (CEST) To: Andrew Sullivan , dnssd@ietf.org References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> <5702C4D3.5070500@rozanak.com> <20160404200942.GE36990@mx2.yitter.info> From: Hosnieh Rafiee Message-ID: <5702D220.2000501@rozanak.com> Date: Mon, 4 Apr 2016 22:44:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160404200942.GE36990@mx2.yitter.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:44:57 -0000 Hi again, On 04/04/2016 10:09 PM, Andrew Sullivan wrote: > > I'm trying to understand what the threat is from a practical point of > view. For instance, there is a claim in the draft about exfiltration. > The truth is that, if you're running split-horizon DNS, you _already_ > have this problem. Therefore, the risk is at worst that there are > more queries that contain such leaks. I don't know whether that's > worse, but I confess I'm pretty sceptical; but those kinds of > considerations need to be laid out. > > It simply isn't true that we just list the threats. We try to lay out > the threats, their severity, the liklihood that they'll happen, and so > on. Listing all the threats in the world would not be useful. The threat is the scope of discovery where causes the services to be available to unwanted domains and most part of this draft emphasis on these kinds of threats. of course it has different consequences and what we actually added to draft as I also explained in private chat in meetecho, is that we have to restrict the scope of discovery for some services specially in .home and homenet. You explained that people would like their home fileservers to be available over the internet and it doesn't matter whether or not we add it to global DNS. But I quite disagree with you because when it is exposed on global DNS server, it can go beyond even the wanted scope that might be defined on edge routers because normally the DNS queries are not filtered on the network edge devices because of enabling clients to use DNS services or enabling outsiders to query the names on global DNS servers inside their networks and map names. That means, any external attacker can also query this global DNS server and can retreive the name of services. Our most emphasis was on homenet services. that means the global DNS server for homenet is somewhere on ISPs and not inside the enterprise. That means all the users of that ISPs can access the services of other users in that ISPs as well as external people.... This is a huge security and privacy risks that it appears that it is easily neglected here. Since, for example, IPv6, unfortunately the ULA is not used for services and services already receive the global IP address, that means, services are accessibile easily to external scope with publishing their names on global DNS server. In other word, it is not only your fileserver that is available to you over global DNS server but also to anyone else in the world. This is why in draft we clearly said that .home domains (that are on going discussion in homenet groups) should be restricted to use global DNS server. Also There need to be restriction on the use of Global IP addresses and instead we use Unique local addresses that are by default not routable over the network and the admin needs to define rules on routers to route them.... This provide a bit of restriction and a bit of security and privacy for exposing services to unwanted domains. This is also what we have confirmed in the draft that unfortunately there was not time to discuss about them. and of course a few sections of the draft discussed about the existing attacks that the global DNS can causes on DNSSD services. >> 2.1.2.1 threat relates to defining a critical service when look-alike name >> detection becomes problematic. >> Unlike DNS, mDNS assumes visual selection IDNA and/or raw UTF-8 allows for >> many possible representations of the same visual representation. By >> allowing all the different representations allowed, this allows look alike >> names. this is why IDNA should be limited for mDNS because there might be >> different services with look alike names that cannot be easily determined. > I'm sorry, but this is just false. First, the problem already exists > with plain LDH, because of l and 1. Second, you can trivially > recreate these problems in IDNA2008 -- Latin-A and Cyrillic-A are the > usual example, but there are many such cases all of which are legal in > IDNA. "Look alike names" are a problem now, with the existing DNS-SD > specification and with other cases (like following links). All of the > rules to solve that -- using mDNS or DNS or YourNewResolutionProtocol > -- need to have these things handled by policy. If the only point is, > "Some policy controls are needed here," say that. But either this is > no more of an issue than any other i18n issue on the Internet, or else > there is something peculiar about this case that makes it more of an > issue. There's been no effort AFAICT to show that the "more of an > issue" case is what is going on here. You can, of course, define it as policy. In my understanding, this policy is a part of the protocol and the restrictions that assigned now as a definition of using such capacity for DNSSD protocol. In other word, the possible problems arises on DNSSD services by using variety of look alike names that need to be take into consideration that at the moment it is not. > Best regards, > > A > Best, Hosnieh From nobody Mon Apr 4 14:58:50 2016 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 0DBBD12D8CC for ; Mon, 4 Apr 2016 14:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTHwjLI3RKu6 for ; Mon, 4 Apr 2016 14:58:44 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8B12D57F for ; Mon, 4 Apr 2016 14:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 839F210B23 for ; Mon, 4 Apr 2016 21:58:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBWyoIbok0oU for ; Mon, 4 Apr 2016 21:58:40 +0000 (UTC) Received: from mx2.yitter.info (dhcp-b2a2.meeting.ietf.org [31.133.178.162]) by mx2.yitter.info (Postfix) with ESMTPSA id 51F6D10AB6 for ; Mon, 4 Apr 2016 21:58:40 +0000 (UTC) Date: Mon, 4 Apr 2016 17:58:37 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160404215837.GE37449@mx2.yitter.info> References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> <5702C4D3.5070500@rozanak.com> <20160404200942.GE36990@mx2.yitter.info> <5702D220.2000501@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5702D220.2000501@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:58:49 -0000 Hi, On Mon, Apr 04, 2016 at 10:44:16PM +0200, Hosnieh Rafiee wrote: > The threat is the scope of discovery where causes the services to be > available to unwanted domains and most part of this draft emphasis on these > kinds of threats. So, then, two things: 1. DNS-SD does not in fact do anything at all to make the services available on the Internet. They're already available. 2. It sounds like your document is better described as, "Consequences of exposing previously-unannounced services via DNS-SD". If that's what you're trying to do, then making that scope crystal clear at the beginning (like for instance, in the abstract) would be good. I still believe the document would benefit from really signficant reorganization, but at least making its goal way clearer would help. > DNS. But I quite disagree with you because when it is exposed on global DNS > server, it can go beyond even the wanted scope that might be defined on edge > routers because normally the DNS queries are not filtered on the network > edge devices because of enabling clients to use DNS services or enabling > outsiders to query the names on global DNS servers inside their networks and > map names. That means, any external attacker can also query this global DNS > server and can retreive the name of services. So, DNS-SD is about service discovery. So it's not too surprising that services that are already available are easier to discover when DNS-SD is in use. That actually does strike me as a potentially useful point to make. > Our most emphasis was on homenet services. that means the global DNS server > for homenet is somewhere on ISPs and not inside the enterprise. Or in the house, or whatever. AFAIK, HOMENET hasn't even established the architecture for this yet. > all the users of that ISPs can access the services of other users in that > ISPs as well as external people. That doesn't follow at all. There are _lots_ of named services in my home net that you can't access, because if you try I'll drop your packets at the edge of my network. Merely knowing the name of something does not guarantee access. Now, knowing the name of something _is_ knowing something that previously one might not have known about. And if the thing is unsecured, it is of course accessible too. Given that the whole point is remote access, however, I can't see how the right answer to that is, "Don't permit service discovery." The _whole point_ is service discovery. > In other word, it is not only your fileserver that is available > to you over global DNS server but also to anyone else in the world. Well, yes. Of course. Presumably this is what authentication and authorization is for. > This is > why in draft we clearly said that .home domains (that are on going > discussion in homenet groups) should be restricted to use global DNS server. This is a completely different issue, unrelated to any of the above. (A globally-ambiguous name akin to RFC 1918 addresses is not obviously a good idea anyway, but regardless its functioning in the global DNS is bound to be obscure.) > You can, of course, define it as policy. In my understanding, this policy > is a part of the protocol I think your understanding is quite mistaken. There is nothing in IDNA to prevent a single label having in it "a" (U+0061) and "а" (U+0430). They're both PVALD. I know of no consumer-grade software in the world that doesn't use the very same bits on the screen to render those two characters. They're as confusable as can possibly be, and there is nothing whatsoever in any protocol to prevent them being used in a way that is possibly confusing to users. > definition of using such capacity for DNSSD protocol. In other word, the > possible problems arises on DNSSD services by using variety of look alike > names that need to be take into consideration that at the moment it is not. So, andrews-laptop.local. and аndrews-laptop.local exhibit this problem, I agree. (The second of those has the Cyrillic "a" in it.) Certainly, anvilwalrusden.com and аnvilwalrusden.com have the same problem. (Again, second one is Cyrillic -- xn--nvilwalrusden-v1k.com). Fortunately for us, Verisign doesn't permit domain names of the second form (because the U-label "аnvilwalrusden" is not all in one script). This is a policy that Verisign has. There is, however, nothing at all in Verisign's policy to prevent me from creating аndrews-laptop.anvilwalrusden.com (xn--ndrews-laptop-v1k.anvilwalrusden.com). And there's nothing in the protocol to prevent it. If you want to say, "Mixed script labels are not allowed anywhere in the DNS," I think you're going to have some push-back. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Apr 12 05:53:22 2016 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 0E9F412EC1D for ; Tue, 12 Apr 2016 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.517 X-Spam-Level: X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk 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 WINKeo-Ps0vs for ; Tue, 12 Apr 2016 05:53:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9534812EBFB for ; Tue, 12 Apr 2016 05:53:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u3CCpMQT030986; Tue, 12 Apr 2016 13:51:22 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u3CCpMQT030986 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1460465482; bh=k4/ZPc8vVSNITiqYb4YU0Ok26p4=; h=From:Subject:Date:Cc:To:Mime-Version:References; b=uY3yfnO6NHXfKcUkDwnyKrkNSsI2zsb5vxc+qtsRDBKHFt4jH2mWZwYGe535A7evb K4mpLaX0AJMTk2FAJf8AeVE9XvyG9ummWKXF7Az6qrAXY9S0CKvDo3Q0fZjwtvmOsc tmWxdjQCNBpYy3bsSamPpokw8yhHvHMHv8mYw1EI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s3BDpM3219207252ZQ ret-id none; Tue, 12 Apr 2016 13:51:22 +0100 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:a93e:5914:9e35:ffe3] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u3CCpIaH018517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2016 13:51:18 +0100 From: Tim Chown Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2016 13:51:17 +0100 Message-ID: To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s3BDpM321920725200; tid=s3BDpM3219207252ZQ; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 References: <9C7B1517-D3F8-4BB2-8FDE-F004FFB8D287@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u3CCpMQT030986 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Terry Manderson Subject: [dnssd] Summary of WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 12:53:18 -0000 Hi, Ralph and I produced a very brief summary of the WG meeting outcomes for = the int-area Wiki, which are copied below. Thanks to everyone for their contributions for the meeting. Hopefully we = can progress the two drafts for the DNS Push work promptly, and in the = meantime get an updated hybrid proxy draft to the IESG. Best wishes, Tim dnssd WG, Monday afternoon session 2, 3:50PM * Chairs=E2=80=99 Introduction * Discussion: WGLC of Hybrid Unicast/Multicast DNS-Based Service = Discovery - draft-ietf-dnssd-hybrid-03 Several WG members supplied input during the WG last call. Stuart = Cheshire responded to that input. He will edit = draft-ietf-dnssd-hybrid-03 according to that input and publish rev-04. = The chairs will review -04 to ensure all comments have been = appropriately addressed and submit the revised draft to the IESG for = publication. =20 * Discussion: Next Steps for DNS Push Notifications - = draft-ietf-dnssd-push-06 There was input during discussion that this document actually specifies = two different behaviours: DNS-over-TCP and DNS updates. The authors = will split draft-ietf-dnssd-push-06 into two documents, one for each = behaviour. * Discussion: WGLC of On Interoperation of Labels between DNS and Other = Resolution Systems - draft-ietf-dnssd-mdns-dns-interop-02 There was only one set of (editorial level) comments from Dave Thaler = about this document during the WG last call. Because the document has = been thoroughly reviewed by the WG during an earlier WG last call, the = chairs have agreed that Dave and Andrew will work together to update the = draft which will then be submitted to the IESG for publiciation. * Discussion: -03 version of Scalable DNS-SD (SSD) Threats - = draft-otis-dnssd-scalable-dns-sd-threats-03 Because discussion of the first two agenda items was prioritised, and = there also being ongoing review and discussion of this document on the = WG mailing list, the presentation was taken off the agenda. * Discussion: New draft: Privacy Extensions for DNS-SD - = draft-huitema-dnssd-privacy-00 The WG appreciates this contribution and encourages further work on the = document, even if there is no specific solution proposed as yet. The AD = confirmed that privacy issues are implicitly within our charter. From nobody Tue Apr 12 20:45:37 2016 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 AB8F612DE7D for ; Tue, 12 Apr 2016 20:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLVhHP0HisAH for ; Tue, 12 Apr 2016 20:45:34 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B39412DD11 for ; Tue, 12 Apr 2016 20:45:33 -0700 (PDT) Received: from [172.16.10.140] (cpe-174-109-142-205.nc.res.rr.com [174.109.142.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id F229925C8E; Tue, 12 Apr 2016 23:43:18 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3B2D67C3-5771-49AF-9655-4BE714231EC0"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: Date: Tue, 12 Apr 2016 23:45:29 -0400 Message-Id: <1503A560-B556-43E8-81FD-DD1D4DC7F941@bangj.com> References: <9C7B1517-D3F8-4BB2-8FDE-F004FFB8D287@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org, Terry Manderson Subject: Re: [dnssd] Summary of WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 03:45:36 -0000 --Apple-Mail=_3B2D67C3-5771-49AF-9655-4BE714231EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 12, 2016, at 8:51 AM, Tim Chown wrote: >=20 > * Discussion: Next Steps for DNS Push Notifications - = draft-ietf-dnssd-push-06 >=20 > There was input during discussion that this document actually = specifies two different behaviours: DNS-over-TCP and DNS updates. The = authors will split draft-ietf-dnssd-push-06 into two documents, one for = each behaviour. To be more specific, after talking with Ray Bellis and Sara Dickinson, = Stuart realized that the Push draft was doing both Push updates and = session management (with the Termination message). This, in combination with the excessive EDNS0 keepalive messages in both = directions made it obvious that it would be better to separate out the = session management into a more general DNS over TCP session extension = draft. We are going to work with Ray and Sara on this. The Push draft will mostly remain the same, but will lose the = Termination message and the EDNS0 keepalives will get morphed into the = session version and only need to be sent at the beginning of the session = or when the keepalive timeout changes. This will simplify the protocol = while providing session management over TCP for other DNS uses. Tom --Apple-Mail=_3B2D67C3-5771-49AF-9655-4BE714231EC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXDcDaAAoJEPk0GMVmUuYMTKEH/imTDFiz1WmEL41kUyKBwy5e ua5M/wJQWW+xXJetWcxlhZgNnzMq+Na66eqzV9XazMV13qjT8SdmhYkG4oL2npPZ hmXkQE7IGktZ5MGyeCtYitezjt7FXRmUqzdBT752Ra528c0LfW1ZqgK57JTwM9Tf gmbyI4fEqhY9a1JkMLNrbDpZVQFec/YSiO+I5xy4lTSpx4BJV0LyAU5ZWiFcXpLp WwNY0IAiYR8lcYsl2O53vMAJahEZUdGGg/H6RKZxIMM5a8zG8pMGYUoRf1pIamI8 fnEsJeY/u/ajze16nkwf5N3dy4vs7TsZPXUA5i36miHjVdE3k0dnb8l3Cg73weE= =7nSU -----END PGP SIGNATURE----- --Apple-Mail=_3B2D67C3-5771-49AF-9655-4BE714231EC0-- From nobody Tue Apr 12 20:52:41 2016 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 1A73C12D507 for ; Tue, 12 Apr 2016 20:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QVD07IM03id4 for ; Tue, 12 Apr 2016 20:52:38 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F28112D56E for ; Tue, 12 Apr 2016 20:52:38 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 2so54981298ioy.1 for ; Tue, 12 Apr 2016 20:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=p3bLxs+QTOOgGIRyZV20UXA5Il66Y+bqlqVJdpeJD8s=; b=bLco86zIDErbTwrs3/tNDDqyMjLeYBSfK9Sdg1Afqv2vwETPrYDSgQ6+9z00aNfYFv C8iuIzqA+XxfkxAf2lOfbkr+4xX378VdqXAKAcc2EReTBrqDicycG2RU8CTofhwJPjEj gZLNNkhL6eS4jeoynTwLoMQYdBANj4Rtw2lhovKuZGvSF7TInuwxcYW27NE4tGwOzkUf ZErdimz/Z6YXX4nyp9zp5gLSHvEgelt3GVrpGXQstVrMsjwCWfseHWCjS2MSgn25O1uB o6vRpLM+YUCN+1bHs7lPN9Yy1whAYLYp91f5BBwpBph/nCxPXE6sKB0Bp2vhO1FzavfV D68g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=p3bLxs+QTOOgGIRyZV20UXA5Il66Y+bqlqVJdpeJD8s=; b=P/Ozkma4hJaKSsQKmctgJbeK2tgk4iDX0RtKKhPzkwh25nxG/eTsuF1S3/cHE2ccIl u+6EgH6OSIqf2nK0wBHiMaQr414uRjMWkopQM1u0lZ0c7hLiASsBBjMzUD2b8ccvJdR8 PIcf1ZT/pBFmzVEGW4Sjrck0oaCA1hK4YWCmEOwWk/O5dFFQ5hcI3+Kzz5ndPuY2JX/b TRYHpA8Naf5Z3MPYQgta2GLyDAWyXFSTiDK5Ll5atzqsKcrJyaZZqUT1nXOH1jIQUL2l KypamG8avznWdIDhH3Ng3sD91yJnFLGtISqD0gVjt/0rBIie+Yq0D1ZH5cJVLWYUHoct ZhBQ== X-Gm-Message-State: AOPr4FXl5S/YpF9GImdL6BnvE6XhCHafK+K1S3BtB8qb8tk0gUXY+mPY9WvyOSC2hTGaKA== X-Received: by 10.107.137.33 with SMTP id l33mr7605299iod.27.1460519557761; Tue, 12 Apr 2016 20:52:37 -0700 (PDT) Received: from still.local ([184.19.161.82]) by smtp.googlemail.com with ESMTPSA id jk7sm3119751igb.3.2016.04.12.20.52.36 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 20:52:37 -0700 (PDT) To: dnssd@ietf.org References: <9C7B1517-D3F8-4BB2-8FDE-F004FFB8D287@ecs.soton.ac.uk> <1503A560-B556-43E8-81FD-DD1D4DC7F941@bangj.com> From: Tim Wicinski Message-ID: <65cd1bd9-41b4-378a-62a0-63828402c52e@gmail.com> Date: Tue, 12 Apr 2016 23:52:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0a2 MIME-Version: 1.0 In-Reply-To: <1503A560-B556-43E8-81FD-DD1D4DC7F941@bangj.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] Summary of WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 03:52:40 -0000 I spoke with Ray and Susan after your conversation, and I felt this was a more generalized way to approach this problem. Also, as DNSOP co-chair, the work should come from there, but the chairs will work with DNSOP on this. tim On 4/12/16 11:45 PM, Tom Pusateri wrote: > >> On Apr 12, 2016, at 8:51 AM, Tim Chown wrote: >> >> * Discussion: Next Steps for DNS Push Notifications - draft-ietf-dnssd-push-06 >> >> There was input during discussion that this document actually specifies two different behaviours: DNS-over-TCP and DNS updates. The authors will split draft-ietf-dnssd-push-06 into two documents, one for each behaviour. > > To be more specific, after talking with Ray Bellis and Sara Dickinson, Stuart realized that the Push draft was doing both Push updates and session management (with the Termination message). > > This, in combination with the excessive EDNS0 keepalive messages in both directions made it obvious that it would be better to separate out the session management into a more general DNS over TCP session extension draft. We are going to work with Ray and Sara on this. > > The Push draft will mostly remain the same, but will lose the Termination message and the EDNS0 keepalives will get morphed into the session version and only need to be sent at the beginning of the session or when the keepalive timeout changes. This will simplify the protocol while providing session management over TCP for other DNS uses. > > Tom > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > From nobody Tue Apr 12 21:01:27 2016 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 6C46512DC58 for ; Tue, 12 Apr 2016 21:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0rXqwULAr7L for ; Tue, 12 Apr 2016 21:01:25 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B6812D9E8 for ; Tue, 12 Apr 2016 21:01:25 -0700 (PDT) Received: from [172.16.10.140] (cpe-174-109-142-205.nc.res.rr.com [174.109.142.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 15CF225C96; Tue, 12 Apr 2016 23:59:12 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9F6A34FF-6828-4E32-9EE4-B8B1511D7CF0"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: <65cd1bd9-41b4-378a-62a0-63828402c52e@gmail.com> Date: Wed, 13 Apr 2016 00:01:23 -0400 Message-Id: <958E83E2-69B5-41A6-9E58-A9A59F6EDF20@bangj.com> References: <9C7B1517-D3F8-4BB2-8FDE-F004FFB8D287@ecs.soton.ac.uk> <1503A560-B556-43E8-81FD-DD1D4DC7F941@bangj.com> <65cd1bd9-41b4-378a-62a0-63828402c52e@gmail.com> To: Tim Wicinski X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] Summary of WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 04:01:26 -0000 --Apple-Mail=_9F6A34FF-6828-4E32-9EE4-B8B1511D7CF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 12, 2016, at 11:52 PM, Tim Wicinski wrote: >=20 >=20 > I spoke with Ray and Susan after your conversation, and I felt this = was a more generalized way to approach this problem. Also, as DNSOP = co-chair, the work should come from there, but the chairs will work with = DNSOP on this. >=20 > tim >=20 Yes, I should have mentioned that it was DNSOP work. And also I forgot = to include Allison Mankin as part of the discussion. Thanks, Tom --Apple-Mail=_9F6A34FF-6828-4E32-9EE4-B8B1511D7CF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXDcSTAAoJEPk0GMVmUuYMB1oIAOUoXZGt3ucXnFQlDYmpGlBC wuRJIFAMxB/PtFWZGjYzo0ZsaGtqVIA8D0guyZ6Pz48YS+9XAv3gGF2CIh4cYVA1 R+laRw2nmaTlmNBL8iJGzgDzXSQYIrmlPVzqmY5/ViTAze7cwsxyqx988qtbDryx aum+EWJJg9243EQd+gTsjYNViph4yUPOn6yrJhXQd3XRjTd1gePBSqfMxZiU46KJ QtGoF1wlZd1Y4kIerWwGfo4bqw1wGloKtRu3DPjRkg1DKqzH0JFWshuN1G/V5NqH nIQMZBfDhLYzB0iSap08SNsaKDxhQrt7vVnbmScrBttd140PQKRKmegF0PnvjMY= =VKFS -----END PGP SIGNATURE----- --Apple-Mail=_9F6A34FF-6828-4E32-9EE4-B8B1511D7CF0-- From nobody Thu Apr 14 03:09:37 2016 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 9126412DDDF for ; Thu, 14 Apr 2016 03:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 Z7X93rr2kEsY for ; Thu, 14 Apr 2016 03:09:27 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8C912DCC5 for ; Thu, 14 Apr 2016 03:09:26 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0212.outbound.protection.outlook.com [213.199.154.212]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-25-Pzu3RI9JSouT1sNR0xsOHA-1; Thu, 14 Apr 2016 11:09:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fUP7aSBalnhdYmUZvkq1T/FjzMYZ1PtuEFeb7gJjYHo=; b=AmNrf8OGhaEIR8pb74OGYtm7KQa8RIjYkn4wRCS6/VALzXlsTSwolDh+s1BsHqUSzy0YoJ/eEzcK7il9MymqsdH0UjITLjqbIUMr4D8GYfKTNYlXqFe3iuXVK9h9cwN1THyh6+gmsKe31HDt3NEbesf8/zI3PofEe7j7biP+uSc= Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB461.eurprd07.prod.outlook.com (10.141.231.139) with Microsoft SMTP Server (TLS) id 15.1.466.12; Thu, 14 Apr 2016 10:09:20 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0466.019; Thu, 14 Apr 2016 10:09:18 +0000 From: Tim Chown To: Tim Wicinski Thread-Topic: [dnssd] Summary of WG meeting Thread-Index: AQHRlMGP6Rv9TFwpDUeP9cX444buVJ+HRFSAgAAB/QCAAfuVAA== Date: Thu, 14 Apr 2016 10:09:18 +0000 Message-ID: <07D1FBB0-C9D2-4CF8-B7FE-4E38079AF9C9@jisc.ac.uk> References: <9C7B1517-D3F8-4BB2-8FDE-F004FFB8D287@ecs.soton.ac.uk> <1503A560-B556-43E8-81FD-DD1D4DC7F941@bangj.com> <65cd1bd9-41b4-378a-62a0-63828402c52e@gmail.com> In-Reply-To: <65cd1bd9-41b4-378a-62a0-63828402c52e@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:dce3:1a00:57b1:5621] x-ms-office365-filtering-correlation-id: 17bc5084-0854-4aac-39db-08d3644cd7a9 x-microsoft-exchange-diagnostics: 1; DBXPR07MB461; 5:HZcMyiBT7Ws9fG4bECvPpM2Qh6lfuBUZrn2n6eGsl9yIaz13pwP+qRofphPlkzgn3p0viuRel2X9iovCL5Jhe3D5vVg4PQsNYLbFb4i/mGLf5c39RpL0LNJsWuyaGKJ+SETbsnquM2Yjo/jZo6BiMrA82C7oWxWcHv7YHxSEYUuhWL1kN7lBDshrPdIWyHlr; 24:gDCUCu8iHeG2DRsorwmYZF6LQzca0uSBAvrGUyfBGufhKmREXY8ReeZaSpRRqW6/o3GDDVNxUm4wxkKCpJEwgumrGK/G3OH+NOngqTs2cxI=; 7:B8pxMIz16hsGHHzRnK/uuf8Kj8AurJ/7gBAkGYsCgh7CFR+DcfZEcYritJgQxJRc2Tuf73KwvmFRGj2AE2AfHIRDahIiSZAvq6TFPderNrVWFlEuGG8+J71cV9/eOyRcu+5K2yRdcS3vlkipuPwpb6KL47BGGjGulNZv+duSpjnWc/y6NuaPOsh/JM1wXpFw0ZgK41WqcqkAREdKbNY3/j0oFPxYqGFFG5vTHKDT3XU=; 20:6c2Mcc0oJQOdBVK4vHj1kb+gtFFjbo9iLCVXiCMAJm1rYQ90ZwwGhcjFTINttrqbx61rSaNuOpCHFfyKt9z5kwVyCiUTxomiKSpNYjzL3hkgGhpe/wdAszK6rhb1m6bYHy1lgMqZVevhHBwJxlrnWl9RXJZJykYWrt3XJJPPuy0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB461; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB461; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(78124002)(50226001)(57306001)(15975445007)(92566002)(77096005)(74482002)(4326007)(106116001)(81166005)(82746002)(10400500002)(2906002)(189998001)(3660700001)(2900100001)(3280700002)(2950100001)(83716003)(122556002)(5008740100001)(110136002)(33656002)(5004730100002)(19580395003)(19580405001)(1220700001)(36756003)(93886004)(76176999)(87936001)(5002640100001)(86362001)(1096002)(50986999)(6116002)(586003)(102836003)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB461; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <82B1A1C350DE38478D2FDBBF9CCB7EC0@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 10:09:18.6918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB461 X-MC-Unique: Pzu3RI9JSouT1sNR0xsOHA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Summary of WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:09:36 -0000 > On 13 Apr 2016, at 04:52, Tim Wicinski wrote: >=20 >=20 > I spoke with Ray and Susan after your conversation, and I felt this was a= more generalized way to approach this problem. Also, as DNSOP co-chair, t= he work should come from there, but the chairs will work with DNSOP on this= . Thanks Tim. >From off-list emails it looks like a draft will appear fairly soon, which d= nssd WG participants will also be encouraged to comment on. Best wishes, Tim >=20 > tim >=20 > On 4/12/16 11:45 PM, Tom Pusateri wrote: >>=20 >>> On Apr 12, 2016, at 8:51 AM, Tim Chown wrote: >>>=20 >>> * Discussion: Next Steps for DNS Push Notifications - draft-ietf-dnssd-= push-06 >>>=20 >>> There was input during discussion that this document actually specifies= two different behaviours: DNS-over-TCP and DNS updates. The authors will = split draft-ietf-dnssd-push-06 into two documents, one for each behaviour. >>=20 >> To be more specific, after talking with Ray Bellis and Sara Dickinson, S= tuart realized that the Push draft was doing both Push updates and session = management (with the Termination message). >>=20 >> This, in combination with the excessive EDNS0 keepalive messages in both= directions made it obvious that it would be better to separate out the ses= sion management into a more general DNS over TCP session extension draft. W= e are going to work with Ray and Sara on this. >>=20 >> The Push draft will mostly remain the same, but will lose the Terminatio= n message and the EDNS0 keepalives will get morphed into the session versio= n and only need to be sent at the beginning of the session or when the keep= alive timeout changes. This will simplify the protocol while providing sess= ion management over TCP for other DNS uses. >>=20 >> Tom >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20