Re: Maintenance WG: ent of Selections

Joel Halpern <> Thu, 28 January 2021 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B6893A1695 for <>; Thu, 28 Jan 2021 11:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9OhwCe7lEVzr for <>; Thu, 28 Jan 2021 11:05:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94AE83A167C for <>; Thu, 28 Jan 2021 11:05:38 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DRVKt2nhMz6GBB6; Thu, 28 Jan 2021 11:05:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1611860738; bh=GC1oGmbgIP+Li9UdwqI/XPL0+R54jISjF5/pHm/bCng=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GUjIGAWD2tpsyC6z0hKYBfwH208vjm+Ozaf3wnKzdEuEiFHl3wetXPGdGuDJEdpDX jR2BDtoZ3d1SkKO4NUbl4/9piOmDE4co4DUmCjem6X2LupB3HyUFrCIcIznGWneKt8 1bvrFKGXYBfINEVKEhK2LLWZYB3PrGy1lvR3HFx8=
X-Quarantine-ID: <L6oQ3nlNbc-8>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DRVKs5yfyz6G84t; Thu, 28 Jan 2021 11:05:37 -0800 (PST)
Subject: Re: Maintenance WG: ent of Selections
To: Phillip Hallam-Baker <>
Cc: IETF Discussion Mailing List <>
References: <> <> <>
From: Joel Halpern <>
Message-ID: <>
Date: Thu, 28 Jan 2021 14:05:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jan 2021 19:05:40 -0000

With regard to maintenance, the two areas I am most active in each have 
enough maintenance that having one WG for all the maintenance (in each 
area) simply would not work.  IDR, LSR, and MPLS for Routing.  6man 
(which is even named as a maintenance group) and DHC (and probably even 
some of the others) in Internet.

Yes, the IETF used to have a policy against long lived working groups. 
We found it didn't work.


On 1/28/2021 11:22 AM, Phillip Hallam-Baker wrote:
> On Wed, Jan 27, 2021 at 7:05 PM Fred Baker < 
> <>> wrote:
>     So voila! IPv4 has existed more than ten years, so we don’t need it
>     any more... Also DNS, DHCP, TCP, Ethernet, SMTP - wow, that rule
>     really clears the deck. And heck - even IETF chairs produce internet
>     drafts.
> Quite. This leads me to re-suggest a proposal I have made from time to 
> time which is that every area have a DISPATCH working group and every 
> area also have a maintenance group.
> This has (sorta) happened in security with LAMPS. Faced with the need to 
> update cipher suites across the board, a new WG was formed which has 
> been tweaking every protocol in active use not in active development.
> The objection generally raised is of course that this allows people to 
> 'mess' with existing protocols adding features that shouldn't be there. 
> But that objection presupposes that the job of the IETF is to control 
> permission for permissionless innovation.
> One of the reasons some WGs linger is that their function requires 
> continuous tweakage, GSSAPI/KITTEN being an example. Better to have one 
> WG with the purpose of lingering than four lingering past their sell-by.