Re: [dnssd] Impending Publication of Discovery Proxy RFC

Ted Lemon <> Fri, 29 May 2020 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 632123A1022 for <>; Thu, 28 May 2020 17:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kRLJkolW-P87 for <>; Thu, 28 May 2020 17:39:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F1213A101E for <>; Thu, 28 May 2020 17:39:01 -0700 (PDT)
Received: by 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;; 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;; 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 ( []) by with ESMTPSA id k190sm6081489qkf.40.2020. (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.\))
Date: Thu, 28 May 2020 20:38:54 -0400
In-Reply-To: <>
Cc: Stuart Cheshire <>, "" <>
To: David Schinazi <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [dnssd] Impending Publication of Discovery Proxy RFC
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

I am okay with this change.  (This is actually the first time I’ve seen it, although I did make that suggestion to Stuart, as he reported.:)

> On May 28, 2020, at 8:32 PM, David Schinazi <> 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 < <>> 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 “subordinate” and “superordinate” 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 “Data Translation” 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 <>") 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 “appropriate” 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 “appropriate” 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 mailing list