[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementation vs. the Standard
A couple of comments inline.
On Thu, 30 Oct 2003, Bound, Jim wrote:
> It is important for us to separate implementation choice vs. the
> standard. The onlink and v6bydefault discussions are mostly a focus on
> if you do this with IPv6 and don't think about this other aspect you can
> hurt yourself.
I'm not sure how to read this. Are you implying that the specifications
could (should) include harmful or dubious features, which clever
implementers could then ignore or work around locally, as a means for
product/vendor differentiation? Probably not, but that's a way to
interpret some of the comments about why things like these are outside the
scope of the specs.
> There is nothing wrong with documenting issues for implementers in an
> RFC and that work should be encouraged. In that context I agree with
> Pekka S. But, for the IETF to tell vendors how they ship their products
> for customers is simply inappropriate and vendors will not listen to the
> IETF, hence this is not a good use of our precious mail time. In that
> sense I agree with Tony 100%.
>
> Discussion of operational issues with our standards and how they work
> with implementation is a good discussion. But should not be a priority
> over the standards work we need to deliver as a working group.
Personally, I disagree with the second paragraph. It is almost criminally
negligent to just push out standards, one after another, without fixing or
documenting issues in the existing ones.
Our number one priority to ensure that the standards and the supporting
advice we generate is accurate, has no known problems and is
interoperable.
From my point of view, broken standards are worse than no standards at
all, hence the need to focus to addressing the issues in the existing
standards.
> I would also add that topics which are standards we are working
> on that are needed and on standards track receive priority mail
> discussion. The Standards Track discussions are the ones that may help
> improve time-to-market for the IETF to deliver their product/solutions
> which are networking standards and the point of this body and forum.
Exactly the reason why I believe these issues are critical. I'm
personally very worried about more than just time-to-market -- rather,
what kind of technology ends up in the market, and if there are flaws in
that technology, how to fix it quickly that the market won't reject it.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings