Subject: Re: [Add] Communication of DNS resolver information for use in selection decisions

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 28 Jan 2021 16:01:46 +0000

I’m top posting because I want to be really clear that the charter does not stop discussion about high-level information needs.   Every should continue to discuss high level needs.

Chris Box wrote…..
“If so, then any discussion of which information clients would like to consume cannot occur under the auspice of this working group….”

High-level discussion of needs is important and needed.  The group can’t work completely in the dark and does need to have some inkling of the information that would be conveyed.   It does explore what’s needed both via use-cases and the problem spaces addressed in drafts.   The charter’s line was drawn against the group getting into working on the details of the information and how the client needed to use it.  So group can and has discussed at a high level what information needs to be conveyed, but not into the information detail or semantics of client use of the information.

If you recall back when various versions of the ADD charter were being proposed and discussed there were proposals that would have involved ADD working on ways to express resolver policies to clients, or legal frameworks and ownership of the resolvers, some even discussed carrying legal documents that would need to be displayed and have required click through semantics specified in the ADD output.      Avoiding such things was the motivation of ADD focusing on Mechanisms.

For example,  the DEER draft includes a certificate as an information container that is being conveyed and the group has discussed it.   The draft even goes as far as stating the certificate needs to have IP addresses.    That’s a high-level description, and appropriate for ADD’s charter.   Where things would have crossed the line into detail would be specifying the certificate format, the various fields of a certificate, the signing rules and interpretation of them, and the semantic meanings of the fields and how clients would interpret and act on them.    We convey certificates, but we don’t define what a certificate is, how it works, or how to interpret it.

The group also obviously does need to get into technical specifics about the transports being specified in drafts, and any signaling used, or containers being carried.    For example, btw-add-home details the bits, fields and values in DHCP to use to describe and communicate resolver descriptive information.  Which is fine and in scope.    It doesn’t stray into specifying the client’s interpretation or decision making based on the information conveyed.

In the end, it’s a matter of situational and contextual interpretation based on the actual discussion and how it’s progressing.

Regards,
glenn

On 1/28/21, 4:38 AM, "Chris Box" <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 28 Jan 2021 at 00:09, Deen, Glenn <[email-masked]<mailto:[email-masked]>> wrote:
As many will recall, when the ADD Charter was bee gruoing approved there was a deliberate choice to limit the scope of ADD.  This excluded ADD from taking on the task of defining the what the actual information that would be provided to clients.   Hence, ADD was chartered to worry about how but not the what.   That means that ADD works on how to convey the information – both in terms of how to transport but also what container to use.

The very deliberate scope limitation crafted into the ADD Charter and approved by both the community advocates for ADD and the IESG was to EXCLUDE ADD from defining the information that is conveyed to the client ...   This means that the conveyance methods give a container to the services that want advertise DNS services and then transport that container to the client.   What specific information the advertising services share is undefined here

Glenn, thanks for clarifying the distinction. I hadn't grasped that it was out of scope to define any of the pieces of data that are carried. Searching for this in the charter, the only way I can obtain that interpretation is from the word "mechanism".

It is chartered solely to develop technical mechanisms.

Define a mechanism that allows communication of DNS resolver
information to clients

I guess you are saying that "mechanism" means "conveyance of a container"??

If so, then any discussion of which information clients would like to consume cannot occur under the auspice of this working group and we should terminate the thread. But I worry this will postpone the definition of any information to be carried by a year or two, meaning we have to accept a world where clients make decisions either blindly, or through the use of multiple proprietary information sources.