[dnssd] Impending Publication of Discovery Proxy RFC

[Stuart Cheshire <[e-mail]>]

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 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 “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