While standards frequently take longer than we like, I would like to
point out several other aspects.
One thing I have observed is that the rush to code often produces work
that needs to be completely reworked. As an example, in ODL the core
adaptation layer had to be rewritten from scratch.
Rushing to produce a wrong standard can be rather more expensive.
On another angle, it often takes significant time to find all the issues
and complications that affect the standard. It takes thought and
discussion.
And finally, the fact that we are trying to reach agreeement across
people who often have very diverse implementations for very good reasons
can create serious obstacle that take time and work to overcome. This
is actually particularly apparent in what should be easy to standardize,
because those are cases where folks have pre-standard implementations
and have often taken very different approaches.
One way of paraphrasing all of the above is that IETF standards take
time because they matter. It is easy to throw something out there, see
if it works, and see if people want to use it. It is not easy to get
something put together that will work well when it is widely adopted.
Yours,
Joel
On 8/1/16 9:42 AM, Livingood, Jason wrote:
On 7/28/16, 10:31 PM, "ietf on behalf of Melinda Shore"
<ietf-bounces(_at_)ietf(_dot_)org on behalf of
melinda(_dot_)shore(_at_)gmail(_dot_)com> wrote:
For one thing, we already have too much work.
In which case, maybe the IETF or certain WGs or Areas are focused on
the wrong work / wrong priorities?
This is completely subjective but my own sense is that the #1
problem we have related to open source projects we take years
to produce specifications.
I certainly agree with that; the pacing of work seems greatly out of
step with what happens elsewhere in our tech community. I think this
tends to seriously scare off people who would otherwise be interested
in or benefit from participating at the IETF.
- Jason