--On Friday, 14 January, 2005 16:26 +0100 Kurt Erik Lindqvist
<kurtis@xxxxxxxxxxxx> wrote:
> On 2005-01-14, at 11.50, Brian E Carpenter wrote:
>
>> John C Klensin wrote:
>>
>>> ... but I note that we are still turning over rocks from
>>> which new issues crawl.
>>
>> And the first year of operation will certainly reveal
>> other issues, which may move faster than a crawl.
>>
>> I am deeply convinced we will be revising this BCP after
>> a year's experience. So I think we will very soon have to
>> agree to leave some known issues open.
>>
>> (fyi, the average lifetime of the first two versions of
>> the IETF standards process and of the Nomcom procedures
>> was 24 months... it seems to take us a couple of iterations
>> and ~4 years to get a process BCP right.)
>
> I would like to voice support for Brian's statement. I think
> that we need to realise that we can't foresee all issues and
> our anticipation's of them are best guesses. There is nothing
> like real-life experience and at some point we need start
> getting that instead of arguing.
Ok. At one level, I agree with this and consider it obvious.
I'm pushing a little harder on (i) getting the things we can
anticipate right and (ii) getting as many of the details as
possible out of the BCP and into the "IAOC figures it out, tells
the community, and listens to feedback" category because...
(1) This administrative process is sucking far more energy out
of the community than, at least in my perception, any of the
standard process retooling activities did, so it would be good
to give us at least a couple of years to recover (and get some
real work done) before we have to even engage on it again.
(2) Some of the details are likely to need reconsideration and
changes much sooner than the 24 months that Brian predicts. If
we can make those adjustments by IAOC procedural actions, it
will be lots better than if they require opening the BCP.
(3) Because money, jobs, and contracts are involved here, the
risks of dealing with inconvenient provisions by simply ignoring
them, with the expectation that the IETF will ratify the changes
later (or that ratification isn't important), are much higher
than they are with the standards process. So any very specific
text in the BCP had best be right and, as a corollary, we should
have as little specific text there as is feasible.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf