Re: [DNSOP] AD review of draft-ietf-dnsop-session-signal

Warren Kumari <warren@kumari.net> Sat, 02 June 2018 20:45 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC515127241 for <dnsop@ietfa.amsl.com>; Sat, 2 Jun 2018 13:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOpY9TIZ27oG for <dnsop@ietfa.amsl.com>; Sat, 2 Jun 2018 13:45:37 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865911270AB for <dnsop@ietf.org>; Sat, 2 Jun 2018 13:45:37 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id d8-v6so8164480wro.4 for <dnsop@ietf.org>; Sat, 02 Jun 2018 13:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NStmujmkA91amRqx5yk9ubleHYecom4tgKubw8GCUtU=; b=Fe6mZub3v2XUu3fSczYzSFDbc42Xo5pnJBqBIa87Bp6vY+uk1c2A1pW9+VP+V/11Uq XOAp/X0GSBZ8GYoSsMZgZ8e/GGf9FT1cy7dvxHQk9pZDVLrpWjlv/rWm6kwGQF52CYHi VA/BzLFEgUGkUhDdEVpXS40w4Ba9X3oBnR0zwq4CgN+fEw9JkWngA5HD/zMl0CMQHzA+ upMpwad2ybiG1rJ/nK/uKmTlhd8jNVFU0v9U0PxlXbI7PV1l3u2kqQgcU95yu5gbtrVh 3YVg1pylmJdHpaeMi7RdANyddomQtIMm8NRKvm2iMfHBdfGkLcqwnC74ABID3A2gzuoB H9gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NStmujmkA91amRqx5yk9ubleHYecom4tgKubw8GCUtU=; b=lVZMLvbyiGZ+Hr/rnn53k+jgA9Jhc11d1LryfPo1lDSajedAFjvv8en+ijOUb82sh9 nWO9w/8CMA8XbjUd56YopHZKVZDILHYmhvhZRZZRhcKRyz1phVfe82S05osyTiLe+16q eMXlHMbRxdjY7wNO2b/Ja+9E5oE5e7er87N9wphF5ozL0LjiXNnWf4490SR0AJ1OeKZu dAZugpSDdbxBGL/UdQtqqXhMsKl4eMrYlo2lp8+fu7Sl2yevwPqjwTH76pBYfVF8hUAh QL/b/T5fGsiNo17dUYTs6pq+WtPjwPeZjYDpFARodmgwdOeicaG5P7SZHmNt5L0DdkFO IB2w==
X-Gm-Message-State: ALKqPwfJw/Y/byWH5IZOHXJhI9pJMixn/NVXVBZHDOYPWodhUzg45e0p MnFDgmY4hpAYhII49CemapnV7ec3kToGix8zDvG6JzXJ
X-Google-Smtp-Source: ADUXVKKgr9w7GQqidS57swiVf98+yz0aXO5X6NlvSiEtxvIbgeA46dRezcsjDK8ISgZY+FwpaZevdqvu3F1pgLj5NDo=
X-Received: by 2002:adf:bbcd:: with SMTP id z13-v6mr12432499wrg.183.1527972335502; Sat, 02 Jun 2018 13:45:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iLrbNXhJYg-wQay-DLjZE_Zty3P90Rx9ZYaH0pGJaaJgQ@mail.gmail.com> <18B9FCA1-CA52-4815-B6CD-C4B5DC3ABCBD@bangj.com> <95C30A14-FF40-43EF-8C31-515691971A60@fugue.com>
In-Reply-To: <95C30A14-FF40-43EF-8C31-515691971A60@fugue.com>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 2 Jun 2018 16:45:24 -0400
Message-ID: <CAHw9_iL3LBbCSL_nXTsBvedBbQSfF6NPwvqqe81SDB+gtAeqSg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Tom Pusateri <pusateri@bangj.com>, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org
Content-Type: multipart/alternative; boundary="00000000000048da2a056daec841"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ePIX-YYffRix-PfU0xorF4TA1qA>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-session-signal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Jun 2018 20:45:40 -0000

That works for me...

W

On Sat, Jun 2, 2018 at 3:37 PM Ted Lemon <mellon@fugue.com> wrote:

> On Jun 2, 2018, at 12:13 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>
> The authors can discuss how they want to change this one or leave it for
> later.
>
>
> I would just suggest that we add:
>
> When an anycast service is configured on a particular IP address and port,
> it must be the case that although there is more than one physical server
> responding on that IP address, each such server can be treated as
> equivalent.   If a change in network topology causes packets in a
> particular TCP connection to be sent to an anycast server instance that
> does not know about the connection, the normal keepalive and TCP connection
> timeout process will allow for recovery.   If after the connection is
> reestablished, the client's assumption that it is connected to the same
> service is violated in some way, that would be considered to be incorrect
> behavior in this context.   It is however out of the possible scope for
> this specification to make specific recommendations in this regard; that
> would be up to follow-on documents that describe specific uses of DNS
> stateful operations.
>
> I would suggest also that instead of "server instance" we say "service
> instance," to avoid creating confusion between a service and a physical
> device that provides that service, of which there could potentially be many
> answering to a single IP address.
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf