Re: bettering open source involvement

"HANSEN, TONY L" <> Fri, 29 July 2016 21:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D05C212D896 for <>; Fri, 29 Jul 2016 14:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1InCM25fJeHD for <>; Fri, 29 Jul 2016 14:45:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32F6C12D512 for <>; Fri, 29 Jul 2016 14:45:19 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u6TLiQeO034669; Fri, 29 Jul 2016 17:45:17 -0400
Received: from ( []) by with ESMTP id 24gesm0w43-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jul 2016 17:45:14 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id u6TLjBkm018937; Fri, 29 Jul 2016 17:45:13 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u6TLisQd018202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jul 2016 17:45:04 -0400
Received: from ( []) by (RSA Interceptor); Fri, 29 Jul 2016 21:44:49 GMT
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Fri, 29 Jul 2016 17:44:49 -0400
From: "HANSEN, TONY L" <>
To: Alia Atlas <>
Subject: Re: bettering open source involvement
Thread-Topic: bettering open source involvement
Date: Fri, 29 Jul 2016 21:44:48 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7783DCB940CF48A7817EAE17A9021843attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-29_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607290217
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 21:45:21 -0000

The fastest I’ve ever gotten an RFC out was 5 months from initial -00 draft to RFC publication.

When it happened:

*) it was an individual contribution for a WG that was already in place
*) it was short, to the point and apropos to the WG
*) people in the WG were interested in it
*) it got reviewed in a single IETF WG meeting cycle, but remained an individual contribution to the WG
*) the AD wasn’t swamped with other items
*) there was nothing controversial in it

So RFCs CAN be done in a minimum amount of time.


From: ietf <> on behalf of Alia Atlas <>
Date: Friday, July 29, 2016 at 9:04 AM

That certainly aligns with what I've heard as well, but can I poke into a bit more.
I know that, for instance, I can get a draft from written to the RFC Editor in 6 weeks,
if it isn't controversial.   Most of that time is to allow adequate review at the WG, IETF
Last Call, directorates and IESG levels.

My sense is that the rest of the time goes to the WG process which has aspects of:
   a) Getting people interested in the idea
   b) Having folks cycle in and out of paying attention and commenting
   c) Having authors/editors be distracted and unresponsive.
   d) Having WG Chairs be distracted/unresponsive and want more discussion first.
   e) Avoiding having actively hard discussions about contentious points.
   f) (sometimes) waiting for implementations to sanity-check

It feels like a WG group or topic in a fixed area with agreement could get past many of these slow-downs - if there were general agreement and a culture in that WG of doing so.

We aren't, after all, doomed to repeat the delays of the past :-)  which isn't to say that this would be easy.

What do you think?  Are there factors that I'm missing?   Is there a technical topic where there could be enthusiasm to push?