Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 13 July 2020 02:25 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC053A08E6 for <ipv6@ietfa.amsl.com>; Sun, 12 Jul 2020 19:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 UjUJ8J7MTWfH for <ipv6@ietfa.amsl.com>; Sun, 12 Jul 2020 19:25:47 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD963A08E4 for <ipv6@ietf.org>; Sun, 12 Jul 2020 19:25:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4B4nZ34bFWz1nwdg; Sun, 12 Jul 2020 19:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1594607147; bh=GJfQ+38sz6BXgxlGzsLi4sd/6+3i3Ljca4h9qUNL51M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=C12IPRW9bPJfFuEsoRM28gH1gaxCUlXkKV9qv2hcIGwK4LDLjpxXkXuzek5jhGK30 n2ZmOyrbcp+ZaHuWYa/QrwpNPFWqc8JybJ1+iB9CewqZss8Whp97A7PJne5sQb1yfJ HoAgzJwQEm7PF1/KLpbh2hOIuwHwbZK19pJraAII=
X-Quarantine-ID: <jS5cyV0tamyY>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4B4nZ271hNz1nsmd; Sun, 12 Jul 2020 19:25:46 -0700 (PDT)
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
To: Michael Richardson <mcr+ietf@sandelman.ca>, IPv6 List <ipv6@ietf.org>
References: <CC295D49-5981-41C3-B4DB-E064D66616CE@gmail.com> <CAFU7BAQX8B2n3FFjQ3h-9VLP7zR=zy0nO0z7bEtz3KXZ7wp=eg@mail.gmail.com> <42267b42-2e29-1bc9-1440-e1a847002efd@gmail.com> <CAKD1Yr1nOPVatXsG+1gdQEpBDmMc6-iby6x_vEN9cVpSY6sNpg@mail.gmail.com> <da41c785-2cc7-7b74-a886-d5202f731498@gmail.com> <dfd12010-5077-186b-e49a-d1fd69bd0e02@joelhalpern.com> <1f0c04ea-5fc4-ad0d-4f51-c18bdccc52f4@gmail.com> <7c61f0a0-5cc3-a8b6-9322-2f886bcd2f79@joelhalpern.com> <16195.1594601473@localhost>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f1bfa222-eee3-529a-5970-4e4d11ebcaea@joelhalpern.com>
Date: Sun, 12 Jul 2020 22:25:43 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <16195.1594601473@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Sd_UIjtjOox4DzjvFVJElVUEr4s>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 02:25:49 -0000

On one level, the meaning of adoption is not clearly written down. 
therefore I can not claim you are wrong.
However, in my experience in many roles at the IETF, your description 
("We adopt documents soe we can put them on the agenda") is not what I 
have seen or done.

We often put individual documents on the agenda.

As I understand it, we adopt documents in a WG when
1) The WG wants to work on the problem; and
2) The WG agrees that the given document is a good starting point for 
the work.

No, it is not the same as WG last call.  There is no goal that the 
document be perfect.  But it is has to be good enough.  As I explained 
to some folks in one WG, if the document does not have enough clarity 
that I understand what the direction is, then no, I do not see how the 
WG can adopt it.  (The authors added the needed clarity.  I believe the 
document will be adopted.)

A working group is not obliged to accept any old text, whether it agrees 
with it or not, as a WG adopted document.

Yours,
Joel

On 7/12/2020 8:51 PM, Michael Richardson wrote:
> 
> Joel M. Halpern <jmh@joelhalpern.com> wrote:
>      > That is a really odd construction Brian.  If the authors are not willing to
>      > make the change, then if the document is to be adopted with a change the
>      > working group is asking for, the WG will have to find a new set of
>      > editors.
> 
> I'm okay with this.
> We don't add consensus building authors/editors often enough.
> 
>      > While again technically allowed, it is not what authors usually mean when
>      > they ask a working group to adopt their document.
> 
>      > But focusing on the fact that technically the document is not yet in the WGs
>      > hands seems to miss the point of the process.  Which is for the IETF to end
>      > up with a document the IETF supports.  So I find your arguments confusing.
> 
> We adopt documents so that we can put them on the agenda.  That's all.
> 
> Over 15+ years, we have confused adoption with WGLC.  It has to stop.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
>