Subject: Rethinking process in the age of DISPATCH

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jul 2021 16:05:39 -0400

Following some discussions in GENDISPATCH, I have been thinking about IETF
process and in particular the relationship between WGs, charters, work
items and how these interact with AD sponsored drafts and the need for
discussion and consensus.

I see the DISPATCH model where an area has a dedicated WG through which new
work is accepted as a best practice. It makes the IETF much more open to
new ideas. But it is an addition that has to work on top of the existing
process rather than a first class element within that process. We could
adapt the process so DISPATCH WGs are more effective.

The possible outcomes of a DISPATCH WG are

1) Refuse the work completely
2) Refer the work to a non-IETF body (IEEE, IRTF, OASIS, W3C)
3) Refer to different area in IETF
4) AD sponsored draft
5) Add the work to an existing WG
6) Charter a new WG

When IETF started, there was an ideological objection to 'standing WGs'. As
with the UK and US bans on 'standing armies' this is obviously
unsustainable. If IETF won't consider extensions to PKIX, some other body
will take over that task. Maintaining protocols such as DNS, HTTP, PKIX,
TLS, SMTP has to be a core part of the IETF mission if it is to be
relevant. The fact that the IETF continues to maintain a protocol is in no
way an obligation on anyone to continue to participate.

So if I was to reorganize the Security Area along these lines, I would have
the following three standing committees

* SEC-DISPATCH
* SEC-AREA (aka SAAG)
* SEC-MAINTAIN (ie LAMPS+CURDLE)

[I would expect the same model to be generally applicable but its easier to
stick to a single specific proposal]

In this model, AD sponsored drafts would not exist. They would be directed
to SEC-MAINTAIN. This has multiple benefits

1) It prevents abuse. I have on two occasions attempted to contribute to an
AD sponsored effort and been told that the process is closed, they are not
required to accept outside discussion or ideas.

2) It ensures that all IETF documents are consensus documents and there has
been an opportunity for participation and review.

Had my proposed changes to CBOR been accepted, COSE would not have been
necessary at all. Instead we have yet another serialization format which I
cannot use for my applications because the encoding is disjoint from JSON
rather than a subset applying the same data model.

The only real difference in the operation of a SEC-MAINTAIN group to a
regular WG is that a proposal need only establish the lack of substantial
opposition, as with an AD sponsored doc, it would not be necessary to
establish substantial support.

Note that this proposal effectively reduces some of the workload of the ADs
as the MAINTAIN WG is effectively taking on the work of managing AD
sponsored drafts. It also provides a mechanism for shutting down WGs that
have ended up in a 'LINGER' state in which the work is basically done but
there are one or two drafts that have not yet completed. These can be
dispatched into MAINTAIN for finalizing.

Of course, it is quite possible that discussions in MAINTAIN would lead to
the discovery that a problem is more complex than expected. In this case
the chairs or AD can kick it back to DISPATCH or just start a WG.

To facilitate this workflow I would modify the concept of a charter so that
instead of the current monolithic model:

Charter =  scope + List<deliverables> + List<milestones>

We have

Charter = scope + List <Work-item>
Work-item = Summary + List<deliverables> + List<milestones>

The reason for doing this is it encourages people bringing a proposal to
DISPATCH to come with a proposed Work-item specifying deliverables and
milestones.

This should reduce the load on the IESG as proposals to add Work-Items to
an existing WG are a specific and limited form of charter revision which is
distinct from discussion of new charters or milestone changes.

With appropriate support from tools we could even automate management of WG
items. When the IESG approves the RFC, the WG item status changes. So
charters would update automatically.