>>>>> "wayne" == wayne <wayne@xxxxxxxxxxx> writes:
wayne> In <200512092141.NAA00720@xxxxxxxxxxx> Bob Braden
wayne> <braden@xxxxxxx> writes:
>> This thread has contained several suggestions that publication
>> of an RFC in the Experimental category constitutes an "IETF
>> experiment".
wayne> This is, in part, due to the directions of the IESG. For
wayne> example, the IESG note that will be placed at the top of
wayne> these drafts refer to things like a two year observation
wayne> period. So, while there isn't anything in RFC2026 that
wayne> documents what the IESG has requested, I don't think the
wayne> "experiment" term is being thrown around quite as loosely
wayne> as might first seem.
I have to agree. While typically the term experimental RFC does not
imply an IETF experiment, I think this is a bit more organized.
I'm not sure there actually is an IETF experiment. However the IESG
has more or less said that anyone wanting to move one of these
technologies onto the standards track needs to come back in some
period of time and demonstrate an IETF experiment took place and
present some conclusions.
Put slightly differently, we cannot force there to be an IETf
experiment. We can encourage people to conduct such an experiment.
We can make an experiment of that type a pre-condition for being on
the standards track. People then need to decide whether having an
Internet standard in this space is worth the effort of conducting such
an experiment and eventually changing their protocol to resolve the
conflicts. If people don't think that's worth the effort, that's
fine; then instead of being an experiment these RFCs will turn into a
documentation of some practice people are deploying on the internet.
so, yes the IESG is sort oof putting an optimistic spin on things by
calling it an experiment. We're hoping people will want to come back
some day, fix the problems and make a standard.
It's clear to me that neither SPF nor Sender ID could achieve the
necessary rough consensus to be a standard-track protocol.
That sometimes happens. The IETF is good at solving problems where
rough consensus is the appropriate decision making mechansim. Some
problems work well that way. Some do not. If your problem does not
achieve rough consensus the perhaps the IETF is not the right place to
bring it [1]. In my mind the major tragidy of marid seems to be that
we were very inefficient at realizing we could not get consensus. It
would have been a lot more efficient, professional and desirable if
people had worked to understand each other and then stated what their
constraints were and on what issues they could not budge. If there
was no way to satisfy all the stakeholders pack up early and go home,
but do so with respect and understanding.
Perhaps I'm wrong. Here's a challenge to anyone who believes they can
get a consensus on this issue. Go get a proposal together and get
agreement from the major stakeholders involved in marid that they will
support your proposal. Ask to publish as an individual submission on
the standards track. If you succeed, the IESG will end up looking
rather foolish. Personally I'd rather play the part of a fool and end
up fixing a big problem than forever fail to reach some important
understanding.
If you do decide to take me up on this challenge I can try to answer
process questions in personal mail. I cannot guarantee that I'll have
a lot of time particularly as questions become more complicated.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf