Subject: Re: /.well-known (RFC5785) vs versioned APIs [and EST/RFC7030]

From: Keith Moore <[email-masked]>
Date: Thu, 7 Mar 2019 10:07:07 -0500

The last thing we need is even more use of DNS[*] to locate services.   
DNS is too often out of sync with reality as it is. A really unfortunate 
consequence of using DNS for service discovery results from a tendency 
to centralize DNS administration within an organization, even if (as is 
often the case) hosts and applications are administered in a distributed 
fashion.   In any organization large enough to have an administrative 
hierarchy, this is a profoundly dysfunctional arrangement.   It gives 
the central DNS administration a huge amount of ability to break things 
(whether due to incompetence, poor communication, or petty turf wars - 
usually some of all of these), whereas the very nature of such an 
organization makes it almost impossible for them to get things right.  
Using DNS for SD in a widespread fashion only exacerbates the problem.

Part of the problem is the too-common notion that there are "public" 
names and "local" names, meaning that the DNS name space is polluted 
with names that aren't in the hierarchy.   A separate, though related, 
problem is that there's no architected way to distinguish one from the 
other.

Keith

[*] By "DNS" here I mean the naming hierarchy, which is of course 
related to the data model.  I agree with you that the current protocol 
is a disaster and that it should be replaced (and yes, it's completely 
doable even without breaking DNSSEC), but fixing the protocol alone 
would not solve this problem.

On 2/26/19 1:57 PM, Phillip Hallam-Baker wrote:
> On Mon, Feb 25, 2019 at 12:01 PM Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Feb 25, 2019, at 17:04, Michael Richardson
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >> So my response to Michael is that you don't want your version
>     numbers in the .
>     >> well-known path, you want them in the DNS records because then
>     they can be
>     >> used to select the host to connect to according to capabilities.
>     >
>     > Interesting. I think that I agree.
>
>     For CoAP, we don’t want to become dependent on DNS.  But we can do
>     similar things with discovery and “rt” target attributes.
>
>
> But what do you mean by DNS?
>
> There is the DNS name registry, the DNS data model and the DNS 
> resolution protocol. All three can be called DNS.
>
> We discussed this at the naming workshop. I see two different types of 
> name, universal so that we all interpret them the same way and local. 
> If I am talking to an Internet of Thing in my house 'open the garage 
> door' is unambiguous. If I am on the Internet, it is not.
>
> We can certainly have a personal name resolution scheme and this 
> should be a standard. But we should not introduce a new data model 
> unless we really need to.
>
> The DNS client-resolver resolution protocol is awful. Lets stop trying 
> to put lipstick on that pig and sidegrade to an alternative resolution 
> protocol that preserves the same data model.
>
>
> One of the reasons I want to establish the convention of resolving the 
> service named 'foo' using the convention it maps to 
> /.well-known/srv/foo/ is precisely so that in protocols such as coap, 
> we can make the service name a transport connection attribute and 
> dispense with .well-known entirely.
>
>
> So putting it together, lets say Carsten has two devices in his house, 
> that support the not-on-fire protocol that is offered over HTTP, CoAP 
> and in one room, Splunge:
>
> _not-on-fire._tcp.carsten.house TXT "trans=coap trans=http"
> _not-on-fire._tcp..carsten.house  SRV 0 10 80 garage.carsten.house
> _not-on-fire._tcp.carsten.house  SRV 0 10 80 kitchen.carsten.house
> _not-on-fire._tcp. kitchen.carsten.house TXT "trans=splunge"
>
> [http://mathmesh.com/Documents/draft-hallambaker-web-service-discovery.html]
>
> The development tools I use allow me to offer XML, ASN.1, JSON, etc 
> encodings of the same service very easily. It is just a switch on the 
> compiler right now. Next generation it will be just a different library.
>
>
> On the naming side, I have a scheme for that as well. But that takes a 
> rather more holistic view of the problem. My basic idea is that if I 
> buy a device, I should be in control of it and it should only interact 
> with me and other devices I specify for it to interact with. It should 
> only use the name services that I nominate and no others.
>