From nobody Tue May 5 10:14:37 2020 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 E5C0B3A0A73 for ; Tue, 5 May 2020 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGXo8rrkMnGo for ; Tue, 5 May 2020 10:14:35 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 1AF8A3A0A52 for ; Tue, 5 May 2020 10:14:35 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 045H2nfa037910 for ; Tue, 5 May 2020 13:14:34 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 30u86mwtvq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 05 May 2020 13:14:34 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 045HEXWL007011 for ; Tue, 5 May 2020 13:14:33 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 045HETKB006888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 May 2020 13:14:29 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 0C1FE4009E84 for ; Tue, 5 May 2020 17:14:29 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30487.vci.att.com (Service) with ESMTPS id ED96D4009E7D for ; Tue, 5 May 2020 17:14:28 +0000 (GMT) Received: from GAALPA1MSGEX1CC.ITServices.sbc.com (135.50.89.110) by GAALPA1MSGHUBAA.ITServices.sbc.com (130.8.218.150) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 5 May 2020 13:14:28 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CC.ITServices.sbc.com (135.50.89.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 5 May 2020 13:14:28 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.1913.007; Tue, 5 May 2020 13:14:28 -0400 From: "STARK, BARBARA H" To: "'dnssd@ietf.org'" Thread-Topic: IETF 108 survey -- really fill it out! Thread-Index: AdYjAGsev9v69EPoSeKMjkCf8jcS6A== Date: Tue, 5 May 2020 17:14:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.207.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-05_09:2020-05-04, 2020-05-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 suspectscore=0 mlxlogscore=539 adultscore=0 priorityscore=1501 mlxscore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 impostorscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050131 Archived-At: Subject: [dnssd] IETF 108 survey -- really fill it out! X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 17:14:37 -0000 Much of dnssd is on the homenet list I just sent this to, and on lots of ot= her lists. But, hey, I'll send this again, anyway. And then go fill it out = myself. Barbara ------------------------ This is a reminder that we need the IETF community to help us plan for the = possibility that one or more upcoming IETF meetings in 2020 and possibly 20= 21 may not be able to go ahead in person. You can help us with this by fil= ling out the following survey:=20 https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to comp= lete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that = you explicitly provide. Thank you in advance for your help. --=20 Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair From nobody Wed May 27 22:07:25 2020 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 861053A0916 for ; Wed, 27 May 2020 22:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o84uyrYJLCCS for ; Wed, 27 May 2020 22:07:20 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 DEB8E3A08FC for ; Wed, 27 May 2020 22:07:19 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04S55fsb051093 for ; Wed, 27 May 2020 22:07:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=cF1UOU0j07S+Hsz5LlN/PePbXOZmqThGuMca8pspOSI=; b=ImTvLUeEQyDoTWqkkPSsBd2RJBHIYTQPSZ9tqoDD2Z9bWl/2hiph4XicoSuI131YibJO r8/VBW01H0YUu/Og89Nxt3OQzanMp6Gv4N2LxFkcxTp6jXR0kJTfJ3Ro/49NeyDafuE/ 4nbQsLZ3FngugFcnocyJYlxsAh1bGOuRjgqo4dr0+18qA6q9tzBn0Txr9wc2X8savVg+ O0H1EISR4B8m4bmA/LBStDIbPo0Bn93+L2wFwmOJENQ2rMbZzjPULNTvWKfCfNJbU1aI +HvcJWpiT6IjNkPo1ZedfrB0TQUetRZTAGFCZvl9SvalssAgloT6qiXiOQHKMesLvjzs yg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3172g3ha25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 27 May 2020 22:07:17 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QB0001XJZK5H0E0@rn-mailsvcp-mta-lapp02.rno.apple.com> for dnssd@ietf.org; Wed, 27 May 2020 22:07:17 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QB000100ZHKJ000@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 27 May 2020 22:07:17 -0700 (PDT) X-Va-A: X-Va-T-CD: e750b37117f6d297f17f6b8b9db13ca5 X-Va-E-CD: 4bf9b469f81437200fbd20d274dbfd39 X-Va-R-CD: bf1007d57e01f04f1aa80ff74865489b X-Va-CD: 0 X-Va-ID: a662763c-ce70-4dc7-8bb3-8a4e56170013 X-V-A: X-V-T-CD: e750b37117f6d297f17f6b8b9db13ca5 X-V-E-CD: 4bf9b469f81437200fbd20d274dbfd39 X-V-R-CD: bf1007d57e01f04f1aa80ff74865489b X-V-CD: 0 X-V-ID: 91956b6a-9d1d-4ec8-b1ec-3911621b5949 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-28_02:2020-05-28, 2020-05-27 signatures=0 Received: from [17.232.171.153] (unknown [17.232.171.153]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QB000JEIZK0EY00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 27 May 2020 22:07:14 -0700 (PDT) From: Stuart Cheshire Content-type: multipart/mixed; boundary="Apple-Mail=_86038414-D216-411F-A3FC-216CBE8CF844" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-id: <5506A068-55D3-4D47-9B37-9AE9AC44CF47@apple.com> Date: Wed, 27 May 2020 22:07:12 -0700 To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-28_02:2020-05-28, 2020-05-27 signatures=0 Archived-At: Subject: [dnssd] Impending Publication of Discovery Proxy RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 05:07:23 -0000 --Apple-Mail=_86038414-D216-411F-A3FC-216CBE8CF844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are wrapping up AUTH48 for DNS Push Notifications and Discovery = Proxy. In doing my AUTH48 reviews, I read RFC 8499 (DNS Terminology) to make = sure I was using DNS terminology correctly. I noticed RFC 8499 = criticizes RFC 5731 (EPP Domain Name Mapping) for introducing the terms = =E2=80=9Csubordinate=E2=80=9D and =E2=80=9Csuperordinate=E2=80=9D but = defining them by example rather than defining them explicitly. I = realized that the Discovery Proxy RFC text was guilty of the same thing. Various important Discovery Proxy data translations are illustrated by = example in different places in the document, and only mentioned = obliquely in the =E2=80=9CData Translation=E2=80=9D section. In = draft-ietf-dnssd-hybrid-10.txt, Section 5.5 begins with the following = text: 5.5. Data Translation 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 appropriate configured DNS Unicast domain. Other beneficial translation and filtering operations are described below. ... The three uses of the word =E2=80=9Cappropriate=E2=80=9D there encompass = quite a lot! The descriptions of the necessary translations are = scattered elsewhere in the document, sometimes explicitly, sometimes = only by example. The information is there, but you have to read the = document attentively to get it all. Others who worked on = implementations, like Ted Lemon and Tom Pusateri, were clear on what = =E2=80=9Cappropriate=E2=80=9D meant because they were actively involved = with the working group throughout. Talking more recently with other = implementers, it has become painfully clear that it is not obvious to = everyone. Following a suggestion from Ted Lemon, I have pulled from examples that = are scattered elsewhere throughout the document, and used them to craft = a clearer summary description in this section. Without this new text I = fear there is a risk of different implementers making different = assumptions, yielding interoperability problems that have to be found = and fixed through painful testing and debugging. The more thorough text for this section is attached, both in plain text = and HTML form. (I recommend the HTML version because it has the example = text nicely formatted in a different font.) Please take a look and check that this new text correctly captures the = intent of the document and protocol. Stuart Cheshire --Apple-Mail=_86038414-D216-411F-A3FC-216CBE8CF844 Content-Disposition: attachment; filename=DiscoveryProxyDataTranslation.txt Content-Type: text/plain; x-unix-mode=0644; name="DiscoveryProxyDataTranslation.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force (IETF) S. Cheshire Request for Comments: 8766 Apple Inc. Category: Standards Track May 2020 ISSN: 2070-1721 Discovery Proxy for Multicast DNS-Based Service Discovery ... 5.5. Data Translation For the delegated rich-text and LDH subdomains, generating appropriate Multicast DNS queries involves translating from the configured DNS domain (e.g., "Building 1.example.com") on the Unicast DNS side to ".local" on the Multicast DNS side. For the delegated reverse-mapping subdomain, generating appropriate Multicast DNS queries involves using the appropriate API mechanism to indicate that a query should be performed using Multicast DNS, as described in Section 5.4. Generating appropriate Unicast DNS responses from the received Multicast DNS answers involves translating back from ".local" to the appropriate configured Unicast DNS domain as necessary, as described below. In the examples below, the delegated subdomains are as follows: Delegated subdomain for rich-text names Building 1.example.com. Delegated subdomain for LDH names bldg-1.example.com. Delegated subdomain for IPv4 reverse mapping 113.0.203.in-addr.arpa. Names in Multicast DNS answers that do not end in ".local" do not require any translation. Names in Multicast DNS answers that end in ".local" are only meaningful on the local link, and require translation to make them useable by clients outside the local link. Names that end in ".local" may appear both as the owner names of received Multicast DNS answer records, and in the RDATA of received Multicast DNS answer records. In a received Multicast DNS answer record, if the owner name ends with ".local", then the ".local" top-level label is replaced with the name of the delegated subdomain as was used in the originating query. In a received Multicast DNS answer record, if a name in the RDATA ends with ".local", then the name is translated according to the delegated subdomain that was used in the originating query, as explained below. For queries in subdomains delegated for LDH host names, ".local" names in RDATA are translated to that delegated LDH subdomain. For example, a query for "thing.bldg-1.example.com" will be translated to a Multicast DNS query for "thing.local". If that query returns this CNAME record: thing.local. CNAME prnt.local. then both the owner name and the name in the RDATA are translated from ".local" to the LDH subdomain "bldg-1.example.com": thing.bldg-1.example.com. CNAME prnt.bldg-1.example.com. For queries in subdomains delegated for reverse mapping names, ".local" names in RDATA are translated to the delegated LDH subdomain, if one is configured, or to the delegated rich-text subdomain otherwise. For example, consider a reverse mapping query that returns this PTR record: 2.113.0.203.in-addr.arpa. PTR prnt.local. The owner name is not translated because it does not end in ".local". The name in the RDATA is translated from ".local" to the LDH subdomain "bldg-1.example.com": 2.113.0.203.in-addr.arpa. PTR prnt.bldg-1.example.com. For queries in subdomains delegated for rich-text names, ".local" names in RDATA are translated according to whether or not they represent host names (i.e., RDATA names that are the owner names of A and AAAA DNS records). RDATA names ending in ".local" that represent host names are translated to the delegated LDH subdomain, if one is configured, or to the delegated rich-text subdomain otherwise. All other RDATA names ending in ".local" are translated to the delegated rich-text subdomain. For example, consider a DNS-SD service browsing PTR query that returns this PTR record for IPP printing: _ipp._tcp.local. PTR My Printer._ipp._tcp.local. Both the owner name and the name in the RDATA are translated from ".local" to the rich-text subdomain: _ipp._tcp.Building 1.example.com. PTR My Printer._ipp._tcp.Building 1.example.com. In contrast, consider a query that returns this SRV record for a specific IPP printing instance: My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local. As for all queries, the owner name is translated to the delegated subdomain of the originating query, the delegated rich-text subdomain "Building 1.example.com". However, the ".local" name in the RDATA is the target host name field of an SRV record, a field that is used exclusively for host names. Consequently it is translated to the LDH subdomain "bldg-1.example.com", if configured, instead of the rich- text subdomain: My Printer._ipp._tcp.Building 1.example.com. SRV 0 0 631 prnt.bldg-1.example.com. Other beneficial translation and filtering operations are described below. --Apple-Mail=_86038414-D216-411F-A3FC-216CBE8CF844 Content-Disposition: attachment; filename=DiscoveryProxyDataTranslation.html Content-Type: text/html; x-unix-mode=0644; name="DiscoveryProxyDataTranslation.html" Content-Transfer-Encoding: quoted-printable RFC 8766: Discovery Proxy for Multicast DNS-Based Service = Discovery
RFC 8766 Multicast Service Discovery Proxy May 2020
Cheshire Standards Track [Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
8766
Category:
Standards Track
Published:
ISSN:
2070-1721
Author:
S. Cheshire
Apple Inc.

RFC 8766

Discovery Proxy for Multicast DNS-Based Service = Discovery

...

5.5. Data = Translation

For the delegated rich-text and LDH subdomains, generating appropriate Multicast DNS queries involves translating from the configured DNS domain (e.g.,=C2=A0"Building=C2=A01.example.com") on the Unicast DNS = side to ".local" on the Multicast DNS side.=C2=B6

For the delegated reverse-mapping subdomain, generating appropriate Multicast DNS queries involves using the appropriate API mechanism to indicate that a query should be performed using Multicast DNS, as described in Section 5.4.=C2=B6

Generating appropriate Unicast DNS responses = from the received Multicast DNS answers involves translating back from ".local" to the appropriate configured Unicast DNS domain as necessary, as described below.=C2=B6

In the examples below, the delegated subdomains = are as follows:=C2=B6

= 
Delegated subdomain for rich-text names       Building 1.example.com.
Delegated subdomain for LDH names                 bldg=E2=80=911.example.c=
om.
Delegated subdomain for IPv4 reverse mapping  =
113.0.203.in-addr.arpa.
=C2=B6

Names in Multicast DNS answers that do not end = in ".local" do not require any translation.=C2=B6

Names in Multicast DNS answers that end in = ".local" are only meaningful on the local link, and require translation to make them useable by clients outside the local link.=C2=B6

Names that end in ".local" may appear both as = the owner names of received Multicast DNS answer records, and in the RDATA of received Multicast DNS answer records.=C2=B6

In a received Multicast DNS answer record, if the owner name ends with ".local", then the ".local" top-level label is replaced with the name of the delegated subdomain as was used in the originating = query.=C2=B6

In a received Multicast DNS answer record, if a name in the RDATA ends with ".local", then the name is translated according to the delegated subdomain that was used in the originating query, as explained below.=C2=B6

For queries in subdomains delegated for LDH = host names, ".local" names in RDATA are translated to that delegated LDH subdomain. For example, a query for "thing.bldg=E2=80=911.example.com" will = be translated to a Multicast DNS query for "thing.local". If that query returns = this CNAME record:=C2=B6= 

  thing.local.               CNAME  prnt.local.
=C2=B6

then both the owner name and the name in the = RDATA are translated from ".local" to the LDH subdomain = "bldg=E2=80=911.example.com":=C2=B6

  thing.bldg=E2=80=911.example.com.  CNAME  =
prnt.bldg=E2=80=911.example.com.
=C2=B6

For queries in subdomains delegated for reverse = mapping names, ".local" names in RDATA are translated to the delegated LDH subdomain, if one is = configured, or to the delegated rich-text subdomain otherwise. For example, consider a reverse mapping query that returns this = PTR record:=C2=B6

  2.113.0.203.in-addr.arpa.  PTR  prnt.local.
=C2=B6

The owner name is not translated because it = does not end in ".local". The name in the RDATA is translated from ".local" to the LDH subdomain = "bldg=E2=80=911.example.com":=C2=B6

  2.113.0.203.in-addr.arpa.  PTR  prnt.bldg=E2=80=911.example.com.
=C2=B6

For queries in subdomains delegated for = rich-text names, ".local" names in RDATA are translated according to whether or not they represent host = names (i.e., RDATA names that are the owner names of A and AAAA DNS = records). RDATA names ending in ".local" that represent host names are translated to the delegated LDH subdomain, if one is = configured, or to the delegated rich-text subdomain otherwise. All other RDATA names ending in ".local" are translated to the delegated rich-text subdomain. For example, consider a DNS-SD service browsing PTR query that returns this PTR record for IPP printing:=C2=B6

  _ipp._tcp.local.  PTR  My Printer._ipp._tcp.local.
=C2=B6

Both the owner name and the name in the RDATA are translated from ".local" to the rich-text subdomain:=C2=B6

  _ipp._tcp.Building 1.example.com.
                    PTR  My Printer._ipp._tcp.Building =
1.example.com.
=C2=B6

In contrast, consider a query that returns this SRV record for a specific IPP printing = instance:=C2=B6

  My Printer._ipp._tcp.local.  SRV  0 0 631 prnt.local.
=C2=B6

As for all queries, the owner name is translated to the delegated subdomain of the originating = query, the delegated rich-text subdomain "Building=C2=A01.example.com". However, the ".local" name in the RDATA is the target host name field of an SRV record, a field that is used exclusively for host names. Consequently it is translated to the LDH subdomain = "bldg=E2=80=911.example.com", if configured, instead of the rich-text subdomain:=C2=B6

  My Printer._ipp._tcp.Building 1.example.com.
                               SRV  0 0 631 =
prnt.bldg=E2=80=911.example.com.
=C2=B6

Other beneficial translation and filtering = operations are described below.=C2=B6

--Apple-Mail=_86038414-D216-411F-A3FC-216CBE8CF844-- From nobody Thu May 28 17:33:03 2020 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 F10983A100D for ; Thu, 28 May 2020 17:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 aQnFwTWk0Xu7 for ; Thu, 28 May 2020 17:32:59 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181803A1006 for ; Thu, 28 May 2020 17:32:59 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id o9so433369ljj.6 for ; Thu, 28 May 2020 17:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jXtC8N8fRfm2nGJzlkX9dgIiG7c0vmkd6732Noc02ZI=; b=a2R9PhwluAySgAX3X2jmTgyFs81lfFSAos5j79AkooQ6REKJ51pO3Sf4H3rahXkMhy MPxljMCp97A+0YAKf+YNO7Io0BAOrYAMnQPoQP6hrc3IBh5G1YKKBwcOloJP+RMjTykH zvPbpLgPhxZsTZ9Ssds0+vXm8aasqgRCgwCt11TCvnhYHnJ8+7l64LGRktW5+fDzxI3w ylxxlRXDmzmK2PTig6OtuJaMWy/sgyhyiq34wYdzrmN2lmDls1HvcCeQ9m33vzcu8Gy8 QjLsOyMGwEfY9AmeU+xj0JzTdRbQrBZ/VMcSfUnU+IBKmpnKcZtS3MLcUTRzrphaPJGV glCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jXtC8N8fRfm2nGJzlkX9dgIiG7c0vmkd6732Noc02ZI=; b=UnvXXWS/DVHi65GedpEf8kqSBedwIObxK9g6X6lvZNntiT+l6jw+2Avt4dJ+vQkx+Q GGvs4SAa2XsRj2xY9RaxM5XXUxIkcS3EKBw2SPlZgZT3LeaXhaNfxJxdu7QlBIcDOzmY ZGReXBnufvU8971qlJXNIuYoYi/lz7CqAD378/c3mWp7FW3kjyZw2uJac3Qye9B7rD2j CHLAnwy5/+DvF74tZCdD7tKt88E6ZxOD0ye0tRiyWUmFxQSeFdCzEpnuunEByWFaUuFs BdOFGxB9HODEp2tJB0KoGYIpsokxrRe4GmtGzNaCWf5Cf+Vhu2oAUzTJ5APXrQgTjrzo 92vA== X-Gm-Message-State: AOAM531PuE5vszT3rJd0k2idsDM92wdc+k191IEo5zQPBC45UoUy8Ei2 6uRbDZiDrPgN2kdw20MLii5/Q3sq0zF3aMubCnqsTQ== X-Google-Smtp-Source: ABdhPJxPsEDxcOQsnGSIjei6nPx/SViO5h9c/KeomFzESeTw+tg+rX10r+69oD7hLxTBjb5CcfqhCd9c6GrBIcGfyYo= X-Received: by 2002:a2e:3e16:: with SMTP id l22mr2836967lja.333.1590712375033; Thu, 28 May 2020 17:32:55 -0700 (PDT) MIME-Version: 1.0 References: <5506A068-55D3-4D47-9B37-9AE9AC44CF47@apple.com> In-Reply-To: <5506A068-55D3-4D47-9B37-9AE9AC44CF47@apple.com> From: David Schinazi Date: Thu, 28 May 2020 17:32:44 -0700 Message-ID: To: Stuart Cheshire Cc: "dnssd@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000de31c05a6be96ec" Archived-At: Subject: Re: [dnssd] Impending Publication of Discovery Proxy RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 00:33:01 -0000 --0000000000000de31c05a6be96ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the update, Stuart! I have reviewed the change that Stuart proposes, and I personally believe that it is positive and editorial; in other words, I do think this change improves the document, and I do not think that this change impacts any normative requirements in the document. Therefore, I believe that this change does not go against any previously established working group consensus, and is acceptable at this stage in the process. However, as chair, I would like working group members to confirm my personal opinion. Please review the change and respond here stating whether you believe that the change is positive and editorial (as defined above). The chairs will collect responses for ten days, and then proceed with publication on 2020-06-08 if no objections arise. Thanks, David On Wed, May 27, 2020 at 10:07 PM Stuart Cheshire wrote: > We are wrapping up AUTH48 for DNS Push Notifications and Discovery Proxy. > > In doing my AUTH48 reviews, I read RFC 8499 (DNS Terminology) to make sur= e > I was using DNS terminology correctly. I noticed RFC 8499 criticizes RFC > 5731 (EPP Domain Name Mapping) for introducing the terms =E2=80=9Csubordi= nate=E2=80=9D and > =E2=80=9Csuperordinate=E2=80=9D but defining them by example rather than = defining them > explicitly. I realized that the Discovery Proxy RFC text was guilty of th= e > same thing. > > Various important Discovery Proxy data translations are illustrated by > example in different places in the document, and only mentioned obliquely > in the =E2=80=9CData Translation=E2=80=9D section. In draft-ietf-dnssd-hy= brid-10.txt, > Section 5.5 begins with the following text: > > 5.5. Data Translation > > 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 appropriate configured DNS Unicast domain. > > Other beneficial translation and filtering operations are described > below. > > .... > > The three uses of the word =E2=80=9Cappropriate=E2=80=9D there encompass = quite a lot! The > descriptions of the necessary translations are scattered elsewhere in the > document, sometimes explicitly, sometimes only by example. The informatio= n > is there, but you have to read the document attentively to get it all. > Others who worked on implementations, like Ted Lemon and Tom Pusateri, we= re > clear on what =E2=80=9Cappropriate=E2=80=9D meant because they were activ= ely involved with > the working group throughout. Talking more recently with other > implementers, it has become painfully clear that it is not obvious to > everyone. > > Following a suggestion from Ted Lemon, I have pulled from examples that > are scattered elsewhere throughout the document, and used them to craft a > clearer summary description in this section. Without this new text I fear > there is a risk of different implementers making different assumptions, > yielding interoperability problems that have to be found and fixed throug= h > painful testing and debugging. > > The more thorough text for this section is attached, both in plain text > and HTML form. (I recommend the HTML version because it has the example > text nicely formatted in a different font.) > > Please take a look and check that this new text correctly captures the > intent of the document and protocol. > > Stuart Cheshire > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000000de31c05a6be96ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the update, Stuart!

I have r= eviewed the change that Stuart proposes, and I personally
believe= that it is positive and editorial; in other words, I do think this
change improves the document, and I do not think that this change
<= div>impacts any normative requirements in the document.

Therefore, I believe that this change does not go against any
previously established working group consensus, and is acceptable
<= div>at this stage in the process.

However, as chai= r, I would like working group members=C2=A0to confirm
my personal= =C2=A0opinion. Please review the change and respond here
stating = whether you believe that the change is positive and
editorial (as= defined above).

The=C2=A0chairs will collect resp= onses for ten days, and then proceed=C2=A0with
publication on 202= 0-06-08 if no objections arise.

Thanks,
= David

On Wed, May 27, 2020 at 10:07 PM Stuart Cheshire <cheshire=3D= 40apple.com@dmarc.ietf.org> wrote:
We = are wrapping up AUTH48 for DNS Push Notifications and Discovery Proxy.

In doing my AUTH48 reviews, I read RFC 8499 (DNS Terminology) to make sure = I was using DNS terminology correctly. I noticed RFC 8499 criticizes RFC 57= 31 (EPP Domain Name Mapping) for introducing the terms =E2=80=9Csubordinate= =E2=80=9D and =E2=80=9Csuperordinate=E2=80=9D but defining them by example = rather than defining them explicitly. I realized that the Discovery Proxy R= FC text was guilty of the same thing.

Various important Discovery Proxy data translations are illustrated by exam= ple in different places in the document, and only mentioned obliquely in th= e =E2=80=9CData Translation=E2=80=9D section. In draft-ietf-dnssd-hybrid-10= .txt, Section 5.5 begins with the following text:

5.5.=C2=A0 Data Translation

=C2=A0 =C2=A0Generating the appropriate Multicast DNS queries involves,
=C2=A0 =C2=A0at the very least, translating from the configured DNS domain<= br> =C2=A0 =C2=A0(e.g., "Building 1.example.com") on the Unicast DNS s= ide to "local"
=C2=A0 =C2=A0on the Multicast DNS side.

=C2=A0 =C2=A0Generating the appropriate Unicast DNS responses involves tran= slating
=C2=A0 =C2=A0back from "local" to the appropriate configured DNS = Unicast domain.

=C2=A0 =C2=A0Other beneficial translation and filtering operations are desc= ribed
=C2=A0 =C2=A0below.

....

The three uses of the word =E2=80=9Cappropriate=E2=80=9D there encompass qu= ite a lot! The descriptions of the necessary translations are scattered els= ewhere in the document, sometimes explicitly, sometimes only by example. Th= e information is there, but you have to read the document attentively to ge= t it all. Others who worked on implementations, like Ted Lemon and Tom Pusa= teri, were clear on what =E2=80=9Cappropriate=E2=80=9D meant because they w= ere actively involved with the working group throughout. Talking more recen= tly with other implementers, it has become painfully clear that it is not o= bvious to everyone.

Following a suggestion from Ted Lemon, I have pulled from examples that are= scattered elsewhere throughout the document, and used them to craft a clea= rer summary description in this section. Without this new text I fear there= is a risk of different implementers making different assumptions, yielding= interoperability problems that have to be found and fixed through painful = testing and debugging.

The more thorough text for this section is attached, both in plain text and= HTML form. (I recommend the HTML version because it has the example text n= icely formatted in a different font.)

Please take a look and check that this new text correctly captures the inte= nt of the document and protocol.

Stuart Cheshire

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000000de31c05a6be96ec-- From nobody Thu May 28 17:39:04 2020 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 632123A1022 for ; Thu, 28 May 2020 17:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRLJkolW-P87 for ; Thu, 28 May 2020 17:39:01 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 0F1213A101E for ; Thu, 28 May 2020 17:39:01 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id dh1so288389qvb.13 for ; Thu, 28 May 2020 17:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pfs/HLEYEwtf/C4PVCdDIQmiSoIw+2yu146O4GTejUU=; b=dssVz1ahn5GkR7lkYn4dCnndG/mfctDRpaorOeDkJyR8FIICiOTNqNQguOpURm3MmP L00EeNBHi60f/QUylFqk27K0LX2TfyLiqLQV17HKVafxFnDdUmNhOjQ9haYUpk8MFwyq 1XiwukJAEwp3pT7iSFJl6bIyUAiYorJ7VK1jhSqTFXztzbuULcLuUyl2PxczIRVGd7qK UlERfhL/6My4jgIlg1Xd2BXznX8ib0SSiieqRmBXnqKzok1/24i2gn2NN5dvYccavTJe 79jzvTRn/ycWKEtxRahq5ScAFFXvP5R+I2iPIXrQRoR3Cjxlovhu024LWrkW2M5gBsg0 c0dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pfs/HLEYEwtf/C4PVCdDIQmiSoIw+2yu146O4GTejUU=; b=hm5H0kZHybo5b/d+nN3EpZufwnYBAL8f+vGKCQMgU/xprM5jVIqfhiTocUMZ5W2pk3 dz8DZDPf0PBz/vkBPvTjv/Vldtnw+N23+HzDVgD03mCwrIXqyGeAltCK3obf1d+dVrht lEN8LGuuBznFsloVar9WvAHq5LP0IN6XchZOqmmM7Hqb9IacaZyRAOsxFx8D6lhSvgms tHOFlNm07hU3jw5KJTvM1q5sqGzqo0Yxcyh5qkZpSl0ZfTNqXsTq4MZ3AegeglzGkwk4 Nym4dodrE0qJ5sweKZeno2RAH3RyXarqZ1q+c+knhuqsjoqxzjMdmb5rhJ98bH9Ps//x IuBA== X-Gm-Message-State: AOAM532VWgqwJiOckbfyWEWW8HiSSJuXY70669It0oq2kFpozHkYlk7w CU+fDXiWAgbJwyAm0mjlci5Clg== X-Google-Smtp-Source: ABdhPJwp7eCe7dfQO2QHX9fYsh38pIc0P3u4hwLcPIz1FzcaJqlT0YB6+dcYQNgpoMh0DY1fBaoteg== X-Received: by 2002:a0c:a98d:: with SMTP id a13mr6039396qvb.157.1590712737687; Thu, 28 May 2020 17:38:57 -0700 (PDT) Received: from penumbra.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id k190sm6081489qkf.40.2020.05.28.17.38.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 17:38:57 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F47D59B4-E5F2-453F-9686-1EF0169BB359" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 28 May 2020 20:38:54 -0400 In-Reply-To: Cc: Stuart Cheshire , "dnssd@ietf.org" To: David Schinazi References: <5506A068-55D3-4D47-9B37-9AE9AC44CF47@apple.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dnssd] Impending Publication of Discovery Proxy RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 00:39:03 -0000 --Apple-Mail=_F47D59B4-E5F2-453F-9686-1EF0169BB359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am okay with this change. (This is actually the first time I=E2=80=99ve= seen it, although I did make that suggestion to Stuart, as he = reported.:) > On May 28, 2020, at 8:32 PM, David Schinazi = wrote: >=20 > Thanks for the update, Stuart! >=20 > I have reviewed the change that Stuart proposes, and I personally > believe that it is positive and editorial; in other words, I do think = this > change improves the document, and I do not think that this change > impacts any normative requirements in the document. >=20 > Therefore, I believe that this change does not go against any > previously established working group consensus, and is acceptable > at this stage in the process. >=20 > However, as chair, I would like working group members to confirm > my personal opinion. Please review the change and respond here > stating whether you believe that the change is positive and > editorial (as defined above). >=20 > The chairs will collect responses for ten days, and then proceed with > publication on 2020-06-08 if no objections arise. >=20 > Thanks, > David >=20 > On Wed, May 27, 2020 at 10:07 PM Stuart Cheshire = > wrote: > We are wrapping up AUTH48 for DNS Push Notifications and Discovery = Proxy. >=20 > In doing my AUTH48 reviews, I read RFC 8499 (DNS Terminology) to make = sure I was using DNS terminology correctly. I noticed RFC 8499 = criticizes RFC 5731 (EPP Domain Name Mapping) for introducing the terms = =E2=80=9Csubordinate=E2=80=9D and =E2=80=9Csuperordinate=E2=80=9D but = defining them by example rather than defining them explicitly. I = realized that the Discovery Proxy RFC text was guilty of the same thing. >=20 > Various important Discovery Proxy data translations are illustrated by = example in different places in the document, and only mentioned = obliquely in the =E2=80=9CData Translation=E2=80=9D section. In = draft-ietf-dnssd-hybrid-10..txt, Section 5.5 begins with the following = text: >=20 > 5.5. Data Translation >=20 > 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. >=20 > Generating the appropriate Unicast DNS responses involves = translating > back from "local" to the appropriate configured DNS Unicast domain. >=20 > Other beneficial translation and filtering operations are described > below. >=20 > ..... >=20 > The three uses of the word =E2=80=9Cappropriate=E2=80=9D there = encompass quite a lot! The descriptions of the necessary translations = are scattered elsewhere in the document, sometimes explicitly, sometimes = only by example. The information is there, but you have to read the = document attentively to get it all. Others who worked on = implementations, like Ted Lemon and Tom Pusateri, were clear on what = =E2=80=9Cappropriate=E2=80=9D meant because they were actively involved = with the working group throughout. Talking more recently with other = implementers, it has become painfully clear that it is not obvious to = everyone. >=20 > Following a suggestion from Ted Lemon, I have pulled from examples = that are scattered elsewhere throughout the document, and used them to = craft a clearer summary description in this section. Without this new = text I fear there is a risk of different implementers making different = assumptions, yielding interoperability problems that have to be found = and fixed through painful testing and debugging. >=20 > The more thorough text for this section is attached, both in plain = text and HTML form. (I recommend the HTML version because it has the = example text nicely formatted in a different font.) >=20 > Please take a look and check that this new text correctly captures the = intent of the document and protocol. >=20 > Stuart Cheshire >=20 > _______________________________________________ > 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=_F47D59B4-E5F2-453F-9686-1EF0169BB359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am okay with this change.  (This is actually the first time I=E2=80=99= ve seen it, although I did make that suggestion to Stuart, as he = reported.:)


On May 28, 2020, at 8:32 PM, = David Schinazi <dschinazi.ietf@gmail.com> wrote:

Thanks for the update, Stuart!

I have reviewed the change that Stuart = proposes, and I personally
believe that it is = positive and editorial; in other words, I do think this
change improves the document, and I do not think that this = change
impacts any normative requirements in the = document.

Therefore, I believe that this change does not go against = any
previously established working group consensus, = and is acceptable
at this stage in the = process.

However, as chair, I would like working group members to = confirm
my personal opinion. Please review the = change and respond here
stating whether you believe = that the change is positive and
editorial (as = defined above).

The chairs will collect responses for ten days, and then = proceed with
publication on 2020-06-08 if no = objections arise.

Thanks,
David

On Wed, May 27, 2020 at 10:07 PM Stuart Cheshire = <cheshire=3D40apple.com@dmarc.ietf.org> wrote:
We are wrapping up AUTH48 for DNS = Push Notifications and Discovery Proxy.

In doing my AUTH48 reviews, I read RFC 8499 (DNS Terminology) to make = sure I was using DNS terminology correctly. I noticed RFC 8499 = criticizes RFC 5731 (EPP Domain Name Mapping) for introducing the terms = =E2=80=9Csubordinate=E2=80=9D and =E2=80=9Csuperordinate=E2=80=9D but = defining them by example rather than defining them explicitly. I = realized that the Discovery Proxy RFC text was guilty of the same = thing.

Various important Discovery Proxy data translations are illustrated by = example in different places in the document, and only mentioned = obliquely in the =E2=80=9CData Translation=E2=80=9D section. In = draft-ietf-dnssd-hybrid-10..txt, Section 5.5 begins with the following = text:

5.5.  Data Translation

   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 appropriate configured DNS Unicast = domain.

   Other beneficial translation and filtering operations are = described
   below.

.....

The three uses of the word =E2=80=9Cappropriate=E2=80=9D there encompass = quite a lot! The descriptions of the necessary translations are = scattered elsewhere in the document, sometimes explicitly, sometimes = only by example. The information is there, but you have to read the = document attentively to get it all. Others who worked on = implementations, like Ted Lemon and Tom Pusateri, were clear on what = =E2=80=9Cappropriate=E2=80=9D meant because they were actively involved = with the working group throughout. Talking more recently with other = implementers, it has become painfully clear that it is not obvious to = everyone.

Following a suggestion from Ted Lemon, I have pulled from examples that = are scattered elsewhere throughout the document, and used them to craft = a clearer summary description in this section. Without this new text I = fear there is a risk of different implementers making different = assumptions, yielding interoperability problems that have to be found = and fixed through painful testing and debugging.

The more thorough text for this section is attached, both in plain text = and HTML form. (I recommend the HTML version because it has the example = text nicely formatted in a different font.)

Please take a look and check that this new text correctly captures the = intent of the document and protocol.

Stuart Cheshire

_______________________________________________
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=_F47D59B4-E5F2-453F-9686-1EF0169BB359--