At 10:30 AM 1/22/2002, Einar Stefferud wrote:
At the minimum, such violations of IETF Standards should be formally noted
in a letter from the IAB to the offending vendor, whoever that might be,
when such information becomes available to the IESG or the IAB.
Among other things, such notices would result in a formally recorded track
record for the offending vendor, which should be made public by CC to the
IETF mailing list, as these are public standards, which are of public
interest and public record.
This assumes that the IESG or IAB care about such violations, in the
interests of promoting vendor conformance with their standards.
Hi Stef,
I think that this misunderstands the nature of the specifications you're
referencing. They are not laws, for which a violation merits some form of
censure. They are specifications for how players are intended to interact
in a process to process conversation. To quote RFC 1122:
These documents are intended to provide guidance for vendors,
implementors, and users of Internet communication software. They
represent the consensus of a large body of technical experience and
wisdom, contributed by the members of the Internet research and
vendor communities.
The fact is that this consensus changes over time, as we learn more about
the technology, and we do a fair bit of work to keep the current consensus
documented. For example, RFC 1122 spends a fair bit on the subject of
all-subnets broadcasts. However (because we subsequently figured out that
they don't work), RFC 1812 says:
4.2.2.10 Multi-subnet Broadcasts: RFC 922
All-subnets broadcasts (called multi-subnet broadcasts in
[INTERNET:3]) have been deprecated. See Section [5.3.5.3].
So what is more important than conformance and conformance testing (which
you will remember the OSI making a big industry out of and yet failing to
have interoperable implementations in any meaningful way) is
interoperability testing. This has traditionally been done in bake-off
events (apologies to Pillsbury) or in labs back at the ranch. One who is
concerned about the interoperability of a set of implementations organizes
it, invites and motivates the various implementors to be involved, works
out a test plan with them, and conducts the test. This presumes an
underlying commitment to interoperate.