Stephane St Hilaire writes:
> > I completely agree. There's *no* IETF-related enforcement -- it's up
> > to customers to complain when a vendor violates an RFC *AND* that
> > violation causes interoperability trouble.
>
> Might is right ! The bigger the customer the more chances he has that is
> complaint will be taken seriously, regardless of its validity. The bigger
> the vendor the less he needs to care about conformance to standards. Sounds
> good to me.
That's about how it works. Assuming you have to live in the real
world, where 800 pound gorillas are able to set wacky "standards" for
all others to follow, this is what you will be living with.
Even where the RFC "proves" that the customer is wrong, large
customers with nice green bills are often considered to be "right."
It doesn't much matter whether we (or anyone else for that matter)
might think this is "good" or "right."
> > I think that lack of specific IETF enforcement is a good thing,
> > because it puts the focus right where it belongs -- on quality of
> > implementation and interoperability rather than on abstract
>
> So being non conformant would make for higher quality (based on what outside
> the IETF authority ?) or even better interoperability ? I don't see how.
Just like I said -- you have to be smart about what you implement and
why. It's not nearly enough merely to read the RFCs and translate
them into semi-functional code. You must *understand* what those RFCs
represent, what your customers will do with the product, and what
other vendors in the same space are doing.
RFCs are by no means a checklist. You won't find a list of
"conditional requirements" as you might in some other documents.
(In fact, there are some well-known implementations of particular
protocols that are just literal translations of the RFCs, and suffer
from substantial interoperability problems resulting from simple
misunderstandings. I don't think it'd be right for me to name them
here, but if you look around carefully, they're not too hard to find.)
> Standard:
> "4 : something set up and established by authority as a rule for the measure
> of quantity, weight, extent, value, or quality"
Note that it says "as a rule" -- not "as the only rule," or even "as
the most important rule."
> > "conformance" to some specification. Using "conformance" as a proxy
> > for correct operation is a problem seen in other standards bodies, and
> > it tends to result in forcing customers to buy all of their equipment
> > from a sole vendor because of minor differences in interpretation.
>
> As opposed to non conformance which insures that every vendor interoperate
> well.
I can't parse that.
The gold standard in Internet design is interoperability -- being able
to communicate with equipment made by many different vendors. The
goal of RFCs is to foster that sort of environment. The primary
standard is still interoperability, which means that in the rare cases
where the documentation says one thing, but everyone implementing that
feature has always done another, it's the documentation that needs to
change.
In other words, you've got the cart in front of the horse. It's not
the documents that are important -- it's the interoperability of
multiple implementations that's important.
> > Or, in other words, vendors are required to be smart, rather than
> > being slaves to the standards process.
>
> Anyone can participate to the standards process so I don't see how anyone
> could become a "slave" to it.
> As for a single vendor thinking that he's smarter than the IETF, it sounds a
> bit arrogant.
Hardly. I see a smart developer who understands the rationale as
being a peer of the people who wrote the document. Knowing and
intentional violations of what the RFC says by someone who is well
versed in the art are *not* a problem. They might well indicate
places where the RFCs should be updated, but not everyone cares to do
that.
Having the working group participants at a particular point in time
think they're collectively smarter than all designers of all types of
equipment is, in my opinion, just as arrogant. They're not; they're
peers.
Unlike some purported standards processes, I think it's a good thing
that RFCs are not considered to be golden references. Certainly, if
you violate anything in an RFC (certainly a MUST, but even a SHOULD or
a MAY), you need to understand what you're doing quite fully and
understand the implications of it.
> > As we well know, there are many possible violations that do not affect
> > interoperability, or that actually make an implementation *more*
>
> I'd be curious to see a list of these violations. I'd even like these to
> show up in some new rfcs or drafts or else what is the point of the IETF in
> the first place ? To publish optional guidelines for vendors to disregard ?
Those lists would be "Internet Drafts" and would eventually become
replacement RFCs to correct the original ones.
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
I don't recall if you're the one stuck behind that broken gateway, but
if you're not, please turn HTML off. Talk about broken software ... :-/
--
James Carlson, Solaris Networking <james.d.carlson@xxxxxxxxxxxx>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
|
