[openpgp] overlapping draft conclusion (Was: a new draft overlapping the WG draft)

[Stephen Farrell <[e-mail]>]

Hi all,

We asked:

  > The top level issue for the WG at this point is whether we
  > (a) change course to work more in line with [1], or,
  > (b) continue with the close-to-done WG draft [2], or,
  > (c) try to tread a line in between.

And many of you sent many thoughtful responses. Thanks
for those. (*)

Our conclusion is that the WG want to continue and
finish crypto-refresh, [2] but to do so in a manner
that, *where feasible*, reduces potential conflicts with
Werner's draft [1]. We do not think the WG wanted to
avoid conflict at all costs, as that's likely not
possible, would take a long time and would be liable
to having to be re-done should [1] change in the
meantime.

So, that leaves the WG the task of figuring out how
to finish [2] and find/mitigate conflicts with [1]
that we have rough consensus are worth changes in [2].

Our plan for that is as follows:

- we'll ask the editor (Paul) to push out a new version
of crypto-refresh that includes all the changes that have
rough consensus so far (primarily the issues discussed at
IETF-114 - dkg is checking that list and will send mail
later)

- once we have crypto-refresh-07 out, we'll start a
working group last call on that, specifically asking
that people who care identify anything they think
needs changing in order to reduce conflict with [1],
but also asking for the concrete changes they'd make
to handle that conflict. That does put an onus on
people to do a fair bit of work, but we think that's
the best way to identify conflicts so that the WG
can reach consensus as to whether to make changes or
not. (And get finished before the end of the universe;-)

- that'll still also be a "normal" WGLC too though,
so people can raise any other issues they find with
draft-07 as part of that

- we can discuss issues arising at IETF-115 as needed
(we're not sure of the exact timing of the WGLC yet,
more on that once we've had a chance to talk to the
editor about that)

We'd also like to ask people to be careful how they
describe [1] in discussions: [1] is an individual
submission that is perhaps unlikely to ever become an
RFC(**), so, given the complex history, referring to [1]
as "4880bis" or anything similar is liable to confuse
people. So please be careful to refer to [1] by it's
URL or draft name (or draft-koch maybe) to avoid that
kind of confusion.

If you disagree with this outcome, there are appeal [3]
processes you can exercise. The first step there is to
ask us as chairs to reconsider, next would be to ask our
AD, then the IESG etc should one want to continue the
appeals process. We point this out not to encourage you
to appeal but rather because welcoming such is a good
part of the IETF process, and as chairs, if someone does
feel the need to appeal, the earlier we see that the
better. (If someone decides later to make an appeal on
this point, they'll probably also then have to say why
they didn't start that now so we might be saving our
future selves, ADs or IAB members some time as well:-)

We realise this is all far from an optimal outcome, but
we're in "find the least bad" territory at this point
and our conclusion is that the above is a local maximum
(in the space of possible outcomes) that makes sense to
take.

Cheers,
dkg and Stephen.

(*) A few responses tended towards discussing the
personnel or history, rather than the specifications.
We responded to some such offlist but plan to jump
more actively on any future postings of that nature,
so please: just don't go there.

(**) The IETF won't make [1] an RFC while there is an
active openpgp WG without asking us what we think, and
we've just done that. If/after the WG has closed, the
IESG would be asked the same and would base their answer
on ours, at least for some years to come. In that time
frame one could envisage [1] being published as an RFC if
sufficient disclaimers as to it's status were added to
explain it describes a path-not-taken by the IETF WG
but implemented by some. (And in case someone asks, we
do not believe doing that work ought be part of our WG
charter in the short term - as this thread has shown,
we don't and won't have change control over [1] in any
relevant time frame.)

[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-2015-rfc4880bis/
[2] https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/
[3] https://www.ietf.org/standards/process/appeals/