[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] [secdir] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some cry
From:       Donald Eastlake <d3e3e3 () gmail ! com>
Date:       2019-03-18 17:50:02
Message-ID: CAF4+nEEUZJ4s2N4UtAySrJ3XD9X9guOOctenqcbHhVOUMBFo4Q () mail ! gmail ! com
[Download RAW message or body]

On Sun, Mar 17, 2019 at 9:29 PM denis bider <denisbider.ietf@gmail.com> wrote:
> 
> With regard to shutting down - I think that policy is doing an incredible \
> disservice to the internet, to both developers and users of protocols.

There can also be inactive WGs that stop meeting (if they were having
meetings) and don't have any active milestones they are working on but
are still around. Or a WG's charter could be changed so that all it
has to do it review related documents that come up. For example, for a
while, PPPEXT was such a WG that existed just to review new documents
that came along related to PPP.

> ...
> The way it works right now is, a group forms around standardizing a protocol, the \
> RFCs are done and the group disbands. Just like that, an entire community that \
> formed around that protocol disappears. When people want to introduce extensions, \
> there's no longer anywhere to turn to. So development of extensions happens \
> haphazardly, without discussion, without feedback, without coordination.

The real community in the IETF is the mailing list which is normally
continued when a WG terminates. So, in the cases I am familiar with,
the community is still around. Although the PPPEXT WG was eventually
terminated, the pppext@ietf.org mailing list still exists with PPP
experts on it.

> I think this policy (of shutting down WGs) is braindead, personally. Working groups \
> should shut down only for things that are actually dead. Not when there's a \
> temporary hiatus before the next version.

What makes something "actually dead"?

In any case, the IETF is what it is. It evolves slowly. There are
always protocol/technical areas moving into the IETF and others moving
out of the IETF. There are usually around 150 WGs these days.
Presumably you would prefer this number to be much larger but that
would imply more than changing philosophy on WG termination, such
changes in management structure and funding.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

> On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal <uri@mit.edu> wrote:
> > 
> > If CFRG is doing what a WG is supposed to - what's the product is supposed to \
> > produce, what are the milestones, and when is it supposed to wind down, as any \
> > normal WG should when it's done the job it was chartered for? 
> > Sent from my test iPhone
> > 
> > > On Mar 17, 2019, at 05:25, Paul Wouters <paul@nohats.ca> wrote:
> > > 
> > > 
> > > > > On Mar 16, 2019, at 12:30, Paterson Kenneth <kenny.paterson@inf.ethz.ch> \
> > > > > wrote:
> > > > 
> > > > The rough consensus of those who joined the discussion is that we should \
> > > > leave the status of CFRG as it is for now.
> > > 
> > > I wasn't aware we were gathering consensus already and thought we were just \
> > > having a discussion. So seeing this cut short all of a sudden with a tally \
> > > seems wrong to me. 
> > > So for consensus, I think that what CFRG is doing matches a WG more than an RG, \
> > > and it would be more formally correct to change it. 
> > > Paul
> > > 
> > > 
> > > _______________________________________________
> > > secdir mailing list
> > > secdir@ietf.org
> > > https://www.ietf.org/mailman/listinfo/secdir
> > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]