John,
Thank you for upleveling. I plead guilty to wandering through the detailed
design.
I agree without comment with the rest of your observations, but one stuck
out.
(2) As the discussion goes on, if appears to me that, in
practice, an SG is little more than a normal WG with an
unusual set of charter-time constraints. While unusual,
those constraints are well within the boundaries of what
the IESG is permitted to do today. Indeed, I believe
that groups have been chartered under constraints and
with responsibilities not appreciably different from
those that would apply to an SG.
If your understanding of the intention for SGs is correct (and I think it
is), and if current process BCPs allow this mode of operation (and I think
they would), I'm wondering if this draft should be published as an ION.
ftp://ftp.rfc-editor.org/in-notes/rfc3933.txt is intended for process
CHANGES. As we both know, the goal was to describe a lightweight alternative
to formal/two-BOFs-plus-a-WG change to formal BCPs - RFC 3933 experiments
are still relatively heavyweight, compared to publishing an ION.
Perhaps all that is required is to describe a style of WG charter, since the
IESG already has discretion to charter as many, or as few, WGs with this
style of charter as seems appropriate, and has discretion to continue doing
that, or to stop doing that, as results seem to dictate.
If there are formal process changes required (doesn't matter what change,
only that SGs require something that is explicitly disallowed in RFC 2418),
then a process experiment would make sense, but if we don't change formal
processes we don't have to worry about unintended side effects that require
formal process change AGAIN to fix (with
http://www1.ietf.org/mail-archive/web/ietf/current/msg48434.html for a
recent example of what "require formal process change AGAIN to fix" looks
like, for anyone else who might have missed it).
Thanks,
Spencer
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf