"Ash," == Ash, Gerald R (Jerry) <gash(_at_)att(_dot_)com> writes:
Ash,> Happy New Year to all! Many thanks to Yaakov for his
Ash,> excellent handling of the list discussion. I'm not very
Ash,> surprised with the way it has gone. Déjà vu all over
Ash,> again :-)
Ash,> The challenge is to focus the discussion to try to reach
Ash,> consensus on moving forward with a process change, i.e., we
Ash,> need to take baby steps to make progress.
Ash,> I'd suggest we try to reach consensus first on the
Ash,> following: Alternative format(s) for IDs, in addition to
Ash,> ASCII text, should be allowed.
I'd like to propose something I hope is simpler to act on.
I'd like to get in the habit of asking people who propose process
changes that are hard to get consensus on to conduct RFC 3933
experiments. So in this particular case please restructure your draft
as in experiment. Find some working groups or authors who would
benefit. Find some rfc editor staff and an AD who would be willing to
help you out. Propose a time limit and let's see if the world comes
to an end if we publish a few documents that are not in ASCII. I
suspect we'll all survive.
I think there are a lot of good reasons why we should do this.
The first is that as part of evaluating plausibility of experiments we
can make sure that the experiment could take place. It seems
reasonable to require that those wanting to change the process spend
the effort to make their changes possible. "Hey. I've got these
people over in the PWE3 working group who would really like to have
better diagrams in their specifications. The AD says he would be able
to review the diagrams and thinks it might be more clear. The rfc
editor says they have time and would be willing to try publishing a
few specs with diagrams if the community thinks it is reasonable," is
a lot more compelling as a starting point than "I want the process to
change. I'm going to write text to change the process and you should
all approve it." If in trying to put together the experiment you find
that no one actually would take advantage of your process change or
you find that people along the way don't have time to do additional
work required by your proposed change, then perhaps that's not where
we should be spending our process change energy.
Second, a lot of objections (more so for other process changes than
for this one) fall into the category of "That will never work," or
"that will drown us all in additional paperwork." The nice thing
about experiments is that they can be constructed so that
participation is optional and so that you have flow control at all
stages. "Well, it will either work or not. If it doesn't we will
delay a few documents or efforts that agreed to participate in the
experiment," is a more compelling response than "It will work fine!
I'm willing to risk the entire IETF process on it!" Even if you are
absolutely sure it will work fine, what harm is there in starting out
slow? Also, opt-in experiments are an excellent response to questions
about whether something is useful. If you start out with enough
people who think it is to justify the IESG review cycle and
publication of an experimental RFC, then you have a strong response to
those who question utility: "We think it is useful; let us waste our
own time. We will either be right or wrong."
Another good thing about experiments is that they often do get people
to become familiar with something and that tends to defuse a lot of
negative feelings steming from anxiety about change. I certainly know
I've had strong negative reactions to things in the past and have
reluctantly agreed to try something. Typically I find it is not
nearly as bad as I had feared. Sometimes I find that I was completely
right but that I have significant evidence to point to now helping
others understand the problem. I don't think I'm atypical in this
regard.
Finally, I'm hoping that we can build a culture of constructive
progress around experiments. I think we have consensus that the IETF
needs to change and evolve. Perhaps we can come to consensus that
experiments are a way we can make forward progress. We may not all
like the experiments but perhaps e can decide that a culture in which
we've all agreed to constructively work towards conducting plausible
experiments is the best compromise we can come up with. I'm hoping
that we can get to a point where it is culturally unacceptable to
object to plausible experiments without explaining what the proponents
of the experiment would need to do in order to get around the
objection. I'm also hoping that we can get to a culture where the
response to a long flame war like this quickly becomes "Well, write it
up, convince the people whose work would be influenced to give it a
try and let's go for it." There will still need to be a lot of
compromise; when people have concerns we will need to try and find
ways of collecting the data we need to evaluate the change. We
probably want to establish a culture of conducting experiments anyway
even if we understand that there are some questions they will not
answer. For example I think an experiment about alternative RFC
formats is valuable even though there is no way it will answer
questions about the archival value of things other than ASCII. Still,
if we get to a point where that is the only open question we will have
made significant progress.
Now, there is one thing that people may not like about how I've tried
to define plausible. I claim that the proponents of an experiment
need to convince people who would be doing work to join the
experiment. Implicit in that is the idea that if you are going to
change how the IESG does things, you need to recruit an IESG member at
a minimum. If you want to try a new way of running a working group,
you need to find a WG chair. If you want the RFC editor to do
something different, you need to convince someone from their staff
that they should go along. I think this is a fairly important
constraint because it prevents people from being over committed. It
also provides somewhat of a selection criteria for experiments: we
work on the ones that attract interest at the right places.
One possible objection is that the IESG or other leadership could
starve out experiments. I think it is fair to ask the IESG what
experiments it is working on and if the IESG is not spending time
supporting process change experiments to complain and demand
improvement. It doesn't bother me that the IESG will end up being
able to focus energy on experiments that the IESG believes are most
beneficial/interesting. That does sound like a management
responsibility that it is reasonable for the IESG to be involved in.
If you don't like the results you can try and convince the IESG to
change, you can give feedback to nomcom or in extreme cases you can
dust off that recall petition you've had sitting on your shelf.
So, a challenge. Let's see if we can put together a plausible
experiment for this or some other topic that interests the community.
Let's see if we can get a well-oiled RFC 3933 process running and
let's go improve our organization while building a better Internet.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf