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

Warren Kumari <> Sat, 02 June 2018 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC515127241 for <>; Sat, 2 Jun 2018 13:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XOpY9TIZ27oG for <>; Sat, 2 Jun 2018 13:45:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 865911270AB for <>; Sat, 2 Jun 2018 13:45:37 -0700 (PDT)
Received: by with SMTP id d8-v6so8164480wro.4 for <>; Sat, 02 Jun 2018 13:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Sat, 2 Jun 2018 16:45:24 -0400
Message-ID: <>
To: Ted Lemon <>
Cc: Tom Pusateri <>, dnsop <>,
Content-Type: multipart/alternative; boundary="00000000000048da2a056daec841"
Archived-At: <>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-session-signal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Jun 2018 20:45:40 -0000

That works for me...


On Sat, Jun 2, 2018 at 3:37 PM Ted Lemon <> wrote:

> On Jun 2, 2018, at 12:13 PM, Tom Pusateri <> 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