Re: [Sidrops] ROV with ATOMIC_AGGREGATE

Jeffrey Haas <jhaas@pfrc.org> Thu, 12 March 2020 16:10 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A3B3A0D33 for <sidrops@ietfa.amsl.com>; Thu, 12 Mar 2020 09:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 pxXxvbNMrA3s for <sidrops@ietfa.amsl.com>; Thu, 12 Mar 2020 09:10:32 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 560B33A0D1A for <sidrops@ietf.org>; Thu, 12 Mar 2020 09:10:32 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id CB7AA1E2D3; Thu, 12 Mar 2020 12:16:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD14DB4B-7091-4F87-8C04-33F4D3D39186"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <0460943d5eedd3b31b68659d2942adeff42f906f.camel@workonline.africa>
Date: Thu, 12 Mar 2020 12:10:30 -0400
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Message-Id: <123B852A-61B3-4618-B048-F2E03A52F719@pfrc.org>
References: <bb9da4b2e853897b95a878f344c8e44193b2f632.camel@workonline.africa> <B15A5A6A-6CC9-43C3-AEEE-65CD886D0C8E@pfrc.org> <e7c908238186300d6e3a7b60a50a2fbf656f13a8.camel@workonline.africa> <C266F9BC-3938-400C-AEC8-A72EBD6D5569@pfrc.org> <0460943d5eedd3b31b68659d2942adeff42f906f.camel@workonline.africa>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tDejSyw0as2h7GbAq3LkerGfAEA>
Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 16:10:37 -0000

Ben,


> On Mar 12, 2020, at 11:57 AM, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> wrote:
> I'm in agreement with all of this, except that I'm not sure that I see
> how the argument against deprecation follows.
> Surely the "Treat-as-withdraw" handling is just a stronger "don't do
> that" signal. In fact, in an imaginary strict-ROV-everywhere-world,
> they come down to the same thing. Except treat-as-withdraw is probably
> easier to troubleshoot.

The original "deprecation" text involved trying to remove the code points for sets and all of the implications that has.

We've largely evolved past that in the current proposal.

-- Jeff