Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

Nick Hilliard <nick@foobar.org> Wed, 27 January 2021 23:19 UTC

Return-Path: <nick@foobar.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782D53A0D55; Wed, 27 Jan 2021 15:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 AOFwt5kxMEaL; Wed, 27 Jan 2021 15:19:54 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA993A0D44; Wed, 27 Jan 2021 15:19:49 -0800 (PST)
X-Envelope-To: draft-ietf-v6ops-cpe-slaac-renum@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 10RNJi1S069015 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2021 23:19:45 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
To: Ted Lemon <mellon@fugue.com>
Cc: Fernando Gont <fgont@si6networks.com>, v6ops-chairs@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum@ietf.org, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
References: <160325603610.17357.6914550111489766157@ietfa.amsl.com> <cf025acf-5192-d9a3-a727-8716d9d7b232@si6networks.com> <C68DC427-85A4-4AE7-928A-C92AD2C4488A@fugue.com> <9404f657-dbcb-877d-5a3f-1f3408c3b890@si6networks.com> <30262C9F-D004-4452-9F40-A407D7B396D3@fugue.com> <85f2bc3f-51f5-a5b2-53cd-9b5a52ac227f@si6networks.com> <D563B1C2-EDEE-4352-9096-8E5877046E28@fugue.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <b2937f86-eab8-f571-f64e-4c537d2a7b14@foobar.org>
Date: Wed, 27 Jan 2021 23:19:43 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.45
MIME-Version: 1.0
In-Reply-To: <D563B1C2-EDEE-4352-9096-8E5877046E28@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/20xOX3FYIZZr0VX-23i6VG5quUs>
Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2021 23:19:58 -0000

Ted Lemon wrote on 27/01/2021 22:32:
> Huh. Well, it’s mostly harmless, so I wouldn’t waste any time trying to 
> resolve this—just leave it in. But I don’t think it’s a best practice to 
> do this, so next time it comes up I’d be tempted to argue the point.

as a general observation unrelated both to this draft and to this 
suggestion, at this stage of the ID process, it's often easier to update 
drafts with reviewers' suggestions even if authors don't feel that the 
suggestions are useful or particularly appropriate.

This is a human nature thing: you just want the draft off your to-do 
list and anything which slows this up, like minor quibbles, are easiest 
to deal with by just agreeing with a silent "meh, whatevs".

This also isn't a criticism of reviewers, whose thankless but critically 
important job is usually done to a very high standard, and is made more 
difficult by having to review content in areas which aren't necessarily 
their specialty.

I don't have a solution to this, but it's worth noting that it happens.

Nick