Marshall,
My apologies for not responding sooner to this. I've been in
offsite meetings for the last two days with very limited email
access and have only now been able to study your message and
scan the subsequent comments. Several aspects of these comments
have been influenced by those other notes.
I think this proposed policy still reflects the core problems
that caused my still-pending appeal.
I want to try to state a few principles that generalize from the
IETF-specific provisions and language of 5378 to the other
streams, work around a problem in the way 5378 interpreted what
I believe was the conceptual intent of the WG, and provide a
basis for moving forward.
(1) The Trust does not make policy. The Trust is an implementer
of policies set by the various streams. As part of that
implementation process, the Trust is inevitably going to need to
interpret the stream-set policies and generate details and
specific procedures, but even those are subject to review by the
relevant streams.
There is obviously a line between policies and policy decisions
and implementation of policies and determination of details. I
think we can trust the Trustees to use good sense about that
(subject to appeal) as long as there is general agreement on
these principles. I think that where we are hung up now is that
many of us believe, based on the provisions of BCP 101 and a
general sense of the consensus of the community both when the
IASA was established and now, that the Trust doesn't make
policy. By contrast, the Trustees appear to be making
statements and proposing policies (including this latest draft)
that make them both determiners of policy and of consensus in
bodies whom they are not chosen to represent.
(2) The Trust is not set up to be an interpreter of consensus of
the bodies associated with any particular stream. In general,
each stream has its own mechanism for making consensus
determinations. If those mechanisms are inadequate in any way,
the problem is not the Trust's to solve.
(3) A corollary to the Trust's role as an implementer of
policies is that the Trust and its Counsel have a key role in
determining the feasibility of policy decisions coming from the
streams. If the Trust determines that a particular policy
cannot be implemented without negative legal consequences or
significant negative procedural ones, then the Trust can, and
should, bounce the policy back to the originating stream with an
explanation. It may be useful to think of that "bouncing"
process as as an appeal from the Trust to the Stream, but an
appeal that is explicitly of the character of "you missed some
important issues when you agreed to this and sent it to us, here
are the issues, please rethink your decision". While it is
obviously desirable to have that sort of response on a timely
basis, there should not be a fixed time limit.
I note that application of (3) would have prevented the
situation in which the Trust felt obligated to try to enforce a
narrow reading of 5378, with that enforcement effective at a
time when the Trustees and community already understood that
doing so would cause fairly serious problems.
In broad outline, where the above would take us as a Trust
procedure for dealing with policy changes is:
(i) Policy change suggestions originate with the streams. It is
their responsibility to determine what is important and what is
not and to determine whether they have sufficient consensus for
a change. If the Trustees determine that changes are needed for
a particular stream, they are free to propose those changes to
the body responsible for the stream, using the processes of that
body. Typically they will act as individual participants in the
work associated with that stream or, if necessary, by generating
suggestions transmitted as liaison notes (if the latter were
needed very often, I think it would be a sign that we had
succumbed to terminal bureaucracy).
(ii) When the body associated with a stream concludes that it is
ready to establish a new policy, that policy is submitted to the
Trustees (and, presumably, to Counsel) for review and comment
(not approval -- whether the Trustees "like" the policy or not
is not at issue here). If the Trustees believe the policy can
be implemented in a way that is legally and procedurally sound,
they proceed to drafting such implementation details are
appropriate. Those details are then presented back to the
relevant stream body for approval and signoff (or rejection and
either adjustment of the policy or further discussion). If the
Trustees believe that the policy cannot be implemented in a
legally and procedurally sound way, they return the policy
specification to the stream body with an explanation adequate to
enable that body to perform a thoughtful and informed review and
reevaluation.
That is all. The key issue, as others have suggested both in
the discussion on this thread and in earlier ones, is that there
is no problem until some stream (or the approving bodies and
processes for that stream) are convinced that there is a
problem. Except in real emergencies, if the Trustees are
convinced that there is a problem, their job is to convince the
stream, not to start making policy.
And, yes, I think there needs to be a provision for rapid action
in an emergency. If it is ever exercised, I think the Trustees
should feel considerable obligation to be exceptionally open and
transparent and to devise a solution that whose reversal would
cause as little damage as possible if the relevant community
eventually decided that a different solution was appropriate.
And I would assume that the relevant communities would deal with
any regular pattern of abuse of emergency provisions with
extreme hostility.
I note, because he and I often disagree on these matters, that...
--On Monday, August 17, 2009 22:10 -0400 "Joel M. Halpern"
<jmh@xxxxxxxxxxxxxxx> wrote:
>...
> There are (at least) two kinds of changes that can occur.
> 1) There can be changes in policy, particularly policy as it
> affects IETF documents. Policy changes that affect the IETF
> have to come from the IETF, with sufficient clear community
> support (at least to the level of rough consensus) for the
> trust to act on.
> 2) There can be changes of mechanism. The trust could learn
> that the mechanism that it adopted has a flaw. For example,
> RFC 5377 specifically leaves the marking determination and
> legal writing to the trust. Within a defined policy. If the
> trust determines it needs to change its mechanism, the whole
> point of that structure was to not need a new RFC. But it
> does require checking with the community to make sure that
> there are no surprise (in particular, this space is full of
> unanticipated side-effects. More eyes can help with that.)
>...
I think we are in complete agreement about the above and that my
comments and stated principles at the beginning of this note are
a generalization of Joel's categorization to apply separately to
each stream.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf