Re: [openpgp] Requesting the editor to step down

I haven't worked deeply in crypto or PGP related code in many years, so
feel free to discard my comments.  I do work extensively in a large
number of open source projects still, often as a member of the
management team, so perhaps my perspective has some merit.
I'll note that you had two main points here, and they are somewhat
muddled together
- the working group suffered from scope creep
- Werner isn't doing a good job as editor
I think these topics would be best separated.
On the scope creep model, you propose throwing out 4880bis and
replacing it with a new draft, and a whole new process for effectively
creating feature branches around a specific feature proposal.  You
further suggest limiting the scope to the originally envisioned scope
of 4880bis.  
I have no comment on whether narrowing scope to the "crypto refresh"
scope.  I'm not enough of a cryptogrphy coder anymore to have an
informed opinion.

So to deal with scope creep, you suggest discarding this draft.  That
seems extreme, and seems like it would greatly slow what little
momentum the working group has.
You also suggest moving to a feature branch model, where individual
described features would exist in a branch, and the branch would garner
comments and fixes from the working group before being merged to
master.  This is a common pattern among open source projects, so I
doubt many would disagree that it has merit.
On your second point, that Werner isn't adequately fulfilling his
duties as editor, you propose that he give up the title.  I have no
comment on this, as I am not following the details closely enough to
have an informed opinion.
You further give as a reasons that the editor should be "fostering
cooperation" ...  I'm not sure that usually falls to the editor, but
rather to the Chair of the working group.
I have little comment on your desire for better communication.
Different teams communicate very differently.  You want more formal
communication of planned merges of features.  That is a proposal worth
discussion.
The IETF process alllows for multiple co-chairs, but formally has only
one Document Editor.  I'll note that this process predates the wide
deployment of distributed version control systems or distributed text
editors.  In many modern open source projects, more than one person has
the authority to merge changes to master.  I would suggest that perhaps
this is a simpler solution...  
- give more than one individual 'co-editor' status to merge changes to
master
- revise the process to a formal feature branch model, one feature per
branch,for all committers
- revise the process to communicate on this list the intended merge of
a given feature branch, and offer opportunity for review, patches, and
comment   
Regards,
Brian

On Fri, 2020-04-17 at 12:18 +0200, Vincent Breitmoser wrote:
> Hi OpenPGP folks,
> Five years ago, the OpenPGP working group was reopened. It was
> chartered asa "crypto refresh" of OpenPGP, and a decision was
> consciously made to not addfeatures beyond that. The newly reopened
> working group strayed from this goalquite a bit, got lost in a
> confused silence, and was closed again due to inactivity.Despite the
> formal status of the working group as closed, rfc4880bis is
> stillbeing worked on. This work happens on this mailing list, but
> most of the actualprogress happens on the openpgp-wg/rfc4880bis
> repository on gitlab:https://gitlab.com/openpgp-wg/rfc4880bis There
> have also been a couple ofreleases of this spec as I-Ds, and it is
> used in practice as a reference byimplementors.
> Since the original reopening, the role of the editor has been held by
> WernerKoch. The formal description of the Document Editor is
> described in [BCP25] as"The Document Editor is responsible for
> ensuring that the contents of thedocument accurately reflect the
> decisions that have been made by the workinggroup." Following this, I
> believe the following to be a reasonable set ofexpectations towards
> an editor:
> 1. Communicate decisions and updates to the working group.2. Foster
> cooperation.3. Work out specification content from group consensus.
> Myself and others have been increasingly dissatisfied with the way
> that all ofthese expectations have not been met in the editing
> process of RFC4880bis. Moresubtle attempts at communicating this have
> failed, which is why I am bringingthe issue up on this list.
> I'd rather spare everyone the exercise, but it seems necessary to
> give a fewconcrete examples of this dissatisfaction. Feel free to
> skip ahead.
> ==
> The repository on gitlab currently has seven open merge requests,
> that have beenopen for many months. Those range from trivial fixes
> for typos, to dkg's work onUser IDs and replacement of Revocation
> Keys, and a fix for a test vector(!) thatreceived no attention in six
> months.
> On the other side of things, Werner commits his own changes directly
> to master,sometimes without any communication.  A recent example from
> two weeks ago, wasthe introduction of a new "key block subpacket":
> https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/30d8397c9fd304691d5628813a38cd61389c76c7
> Regardless of whether this mechanism is a good idea (it probably is),
> or whetherthe spec wording is good (is "key block" the best term?),
> there was no attemptmade to find consensus about it, on this list or
> elsewhere. (This feature wasalso implemented into GnuPG on the same
> day it was pushed to master in the spec,and released as a backport
> into GnuPG 2.2.20 just a few days later.)
> As noted above, the decision process of whether a proposal makes it
> into thespec seems arbitrary at best. But even when consensus is
> achieved, the actualediting process is haphazard. In August of 2019,
> dkg and myself worked outa draft for "attested certifications". This
> work found some consensus on the ml(including from Werner), and
> eventually led to a merge request:
> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/20
> When Justus Winter and Heiko Stamer reviewed this MR, they found an
> oddity aboutthe way that signatures were made, and also two
> typos.  Despite those issuesthat obviously still required attention,
> Werner merged the MR, leaving nocomment and offering no follow-
> up.  The typos and cryptographic oddity of thesignature remain to
> this day.
> Facilitation of cooperation has failed as well. On March 19th last
> year, JustusWinter opened an issue on the repository saying that he
> could not build the specin its current form:
> https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/7
> Six months after the issue was posted, Werner closed it with the
> single remark"I can't replicate that."  dkg reopened the issue,
> noting that the toolchainworks only on Debian stretch (then already
> oldstable by a few months), but didnot in fact work on Debian stable.
> The ticket remains open to this day, eventhough the issue itself was
> eventually resolved with a merge request from dkgthat converted the
> toolchain to kramdown.
> This is not an exhaustive list. I tried to pick examples that
> illustrate theirpoints in a clear way, and hopefully relatively free
> of personal bias.
> ==
> I appreciate the work Werner has put into RFC4880bis, and of course
> into OpenPGPin general. However, a document that is published under
> the ietf-* namespacebears a quality of officialness, and thus an
> expectation to reflect consensus ofthe working group. The draft-ietf-
> openpgp-rfc4880bis-* documents do not, in myopinion and that of
> several others I have talked to, meet this expectation.
> In consequence, I formally request Werner Koch to step down from his
> position aseditor for the OpenPGP specification.
> Of course, this means we will need a new editor. I'm confident that
> we can findsomeone for this role, once the air has cleared a bit.
> As a general thought for a way forward, I would suggest to restart
> work onRFC4880bis conceptually, in the way it was originally
> chartered as a pure cryptorefresh.  A good starting point would be
> for a new editor to bring the originalRFC4880 into a modifiable state
> with a modern toolchain, to allow work on actualset of patches going
> from 4880 to 4880bis. A portion of the changes made onRFC4880bis so
> far certainly don't match the chartered "crypto refresh", so itmakes
> sense to cherry-pick from them in an ordered fashion, with a check
> forconsensus and implementation status.
> I would further suggest to orient future work more on concrete
> proposals, i.e.diffs against the spec. By explicitly asking
> contributors to submit and maintainconcrete patches as a basis for
> discussion, we encourage contributions that arebetter thought out,
> continuously reflect the state of thinking, and can beweighed against
> one another - or combined on their merits - more easily.
> I apologize for bringing up this unpleasant topic. Thanks for
> reading, andconsidering.
>  - Vincent Breitmoser
> [BCP25]: https://tools.ietf.org/html/bcp25#section-6.3
> 
> _______________________________________________openpgp mailing 
> listopenpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
-- 
Brian G. Peterson
ph: +1.773.459.4973
im: bgpbraverock