Re: [dnssd] Impending Publication of Discovery Proxy RFC

David Schinazi <> Fri, 29 May 2020 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F10983A100D for <>; Thu, 28 May 2020 17:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aQnFwTWk0Xu7 for <>; Thu, 28 May 2020 17:32:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 181803A1006 for <>; Thu, 28 May 2020 17:32:59 -0700 (PDT)
Received: by 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;; 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;; 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: <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 28 May 2020 17:32:44 -0700
Message-ID: <>
To: Stuart Cheshire <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000de31c05a6be96ec"
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:33:01 -0000

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.


On Wed, May 27, 2020 at 10:07 PM Stuart Cheshire <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