Re: What is the right way to do Web Services discovery?

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Nov 22, 2016 at 2:42 PM, Jared Mauch <[e-mail]> wrote:

> (Not going to address things where I perhaps disagree, but focus on areas
> of concern …)
>
> > On Nov 22, 2016, at 10:04 AM, Phillip Hallam-Baker <
> [e-mail]> wrote:
> >
> > I am asking here as there seems to be a disagreement in HTTP land and
> DNS land.
> >
> > Here are the constraints as I see them:
> >
> > 0) For any discovery mechanism to be viable, it must work in 100% of
> cases. That includes IPv4, IPv6 and either with NAT.
>
> I think must be sufficiently robust, where it’s defined as 98+%.  Studies
> on the operational networks seem to indicate this is the threshold is in
> the 95-99% range.  Saying 100% is a goal, but perhaps unrealistic.


​Let us remind ourselves of what the purpose of SRV records originally was.
They were developed to improve reliability by enabling fault tolerance.​

​In the commercial world, systems have been expected to be four nines
reliable as a matter of course for a decade. That isn't even state of the
art, it is baseline. There are plenty of services built for 99.9999% up
time. And that is actually essential because if you have a system that can
fail at multiple points, the errors start to accumulate and pretty soon you
have a system that is visibly unreliable.

Any Web Service discovery architecture has to be 100% compatible with the
legacy infrastructure. Because if it isn't it is going to reduce
reliability, not increase it.

Building in SRV means that the cost of achieving 99.99% uptime is reduced.
​But reducing the SLA to 98% would be vastly cheaper.


On Tue, Nov 22, 2016 at 5:38 PM, Mark Andrews <[e-mail]> wrote:

>
> In message <CAMm+LwgtJuLdL_RKJNSVNGODGj8D25nfj0jkhnBLFS=a
> [e-mail]>
> , Phillip Hallam-Baker writes:
>


> > 1) Attempting to introduce new DNS records is a slow process. For
> practical
> > purposes, any discovery mechanism that requires more than SRV + TXT is
> not
> > going to be widely used.
>
> Absolute total garbage.
>
> Introducing a new DNS record isn't slow.  It take a couple of weeks.
> Really.  Thats how long it takes to allocate a code point.
>
> RFC 1034 compliant recursive servers and resolver libraries should
> handle it the moment you start to use it.


​Well until you can persuade the ISPs to provide RFC1034 compliant
interfaces in their Web Configuration tools, the majority of sites will not
be able to use a new record.

Allocating records isn't the problem. The Internet is defined by running
code, not allocated code points.​ Only a minority of network admins
actually edit zone files these days.

​CAA was specified several years ago now. We are only just getting to the
point where it is viable. ​


​It isn't my job to get your specifications deployed by having my systems
break unless people upgrade. ​It isn't anyone's job.

Besides which, we already have an RFC that says use SRV+TXT - RFC 6763.