Re: As Promised, an attempt at 2026bis

> > wtf?  no, you can't make incremental changes and expect the result to
> > work better than what we have now.  in all probability it will work
> > worse, much worse.  the standards process has to balance various
> > factors (e.g quality vs. timeliness).  if you change one aspect at a
> > time without changing the others you throw the thing out of balance. 
> > John's right - it's a recipe for disaster, and it's completely
> > unacceptable as a means of moving forward.
> And this is fear mongering with a complete lack of specifics.  Send
> text, not fear.
And again, if we get into arguments about how to change things then we 
lose the opportunity to document current practice.  I am not sure how 
bad that is in this particular case.  If we were talking about a 
computer-to-computer protocol that was in widespread use, that would be 
a considerable loss.
In this case I suspect (though I could be wrong) that both 2026 and the 
reality that is practiced are fairly well understood here, so as long as 
we can describe new proposals in terms of how they would change things 
from 2026, people in IETF will be able to understand them and evaluate 
how much better or worse they will work than current practice.  It's 
much more difficult to read an entirely new proposal that states things 
in different terms, and evaluate how it will work against an 
organizational culture that is very much steeped in 2026.
Note that there's an important difference between describing a new 
process in relation to 2026 - but describing all of those changes at 
once - and trying to make one change at a time.  I thought you were 
proposing the latter, but I may have misunderstood.
Keith

p.s. As an aside, I do not believe that standards - be they process or 
computer protocol standards - should document current practice.  I 
believe they should document realistic and desirable practice.   the 
standard should be a benchmark that real world implementations strive to 
meet.  Sometimes they will fail.  That's not by itself a justification 
for degrading the standard.  Of course if the standard is unrealistic or 
infeasible, or if it doesn't reflect desirable practice, that's an 
argument to change the standard.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf