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

Phillip Hallam-Baker <> Wed, 23 November 2016 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF8D129DAA for <>; Wed, 23 Nov 2016 05:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9u0Uqtp46u_a for <>; Wed, 23 Nov 2016 05:09:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C494E129D81 for <>; Wed, 23 Nov 2016 05:09:02 -0800 (PST)
Received: by with SMTP id a197so77195660wmd.0 for <>; Wed, 23 Nov 2016 05:09:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=AGpGsSq2/+yXO/LCDocq3AJMwOmdusRuUMi2TcmSbm8=; b=Uo+/ostCPylMHkLKQBoLtznByqh5MLr7/FHlj6BqKrP2Jqe/Tz3um2STofWeTGrwNU HL1S8aCHm0yB4u3s93J/SOcINOYqZvaG9cAs5iF28MDZL5Qub6ZvE2S6TW9nADh4ToNq PcKsuRKsMtOUSLXdp8wy/57rOL46A4iFEXxDgStP/c9WW7IhaxT8tppTJ+sy4bZ6EHCV aEGgAQdydu0QAUL50i5aCWRzfA8sFi7RSxNwVITIi6qDgLOh7BeG3UrA3Ewx7QAK2BHn fkGnkpZHIBh9bhpGsrmL8ihYSa8SKgQxy6y5SKO+Vimzl+0TV6jOWpLrLO4hhGScZwcp 7hAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=AGpGsSq2/+yXO/LCDocq3AJMwOmdusRuUMi2TcmSbm8=; b=gLtdOeRsirFXx9AWooO0/UXp9viEMo9Gh4xdEoziM7GQMhgTiuxGOLKECc3ysIcUc+ FC8tTExd83f2VnWjs+Muy6TEA7otTFLI+E+MuOqrbJADlrtBj6PWRHGMr9OllzjSh25z t6TG4apfxB6eO4tY1tQHjtOUGSm4QitsC3zbAOfg07SqPi6xTNBNVMMwZ5IOw4CiaOcF 5RO52Ss/ZHF9b1mazkLLkoBb0R1gZ2s+4Kejzl2bUQF1rnvqEXDuPMFlvPBHxqKc9rBc dUbffx+YqdQVNijuYCx+JCa2eEJMEiwgAqBA/orQx3lrRq2wj8Td0LXhCoWCfrWBoEhG HkkA==
X-Gm-Message-State: AKaTC026MlWVKxrbShadGnrXqWWi8ItW/J0P82xHROfFznPIyh24g69fKibzWrHDvQrLixHuJHmBx21lXpuobQ==
X-Received: by with SMTP id r4mr3788049wjc.54.1479906540945; Wed, 23 Nov 2016 05:09:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Nov 2016 05:09:00 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Phillip Hallam-Baker <>
Date: Wed, 23 Nov 2016 08:09:00 -0500
X-Google-Sender-Auth: HiRjpr3g-iOdeEOuCa5gs_Tt9bA
Message-ID: <>
Subject: Re: What is the right way to do Web Services discovery?
To: IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="047d7b66fd9dac890c0541f797ee"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Nov 2016 13:09:05 -0000

On Tue, Nov 22, 2016 at 2:42 PM, Jared Mauch <> 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 <
>> 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 <> wrote:

> In message <CAMm+LwgtJuLdL_RKJNSVNGODGj8D25nfj0jkhnBLFS=a
> , 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.