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.
