Stephane St Hilaire writes:
> > 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.
>
> > It doesn't much matter whether we (or anyone else for that matter)
> > might think this is "good" or "right."
>
> I'll have to look at your bank account before I decide whether or not you
> are right about this.
I find that comment completely baffling.
For what it's worth, and it's not much, my bank account is certainly
*not* large.
> > > > I think that lack of specific IETF enforcement is a good thing,
>
> My only contention is that you are saying this is a good thing and I don't
> agree.
> Having seen "The planet of the apes", I'd rather not let 800 pound gorillas
> set the standards.
I think you're greatly misunderstanding what I wrote.
I said that it's a good thing that the IETF doesn't have an
enforcement squad. I did *NOT* say that it's wonderful that monied
interests sometimes make the decisions about what is done -- I simply
said that it's unavoidable reality. One has to live with the fact
that the world works this way.
I do think things would be much *worse* if we elevated the documents
above proven interoperability.
> > 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.
>
> Why would it be semi-functional ? Do you equate RFC compliance with
> semi-functional code ?
Once again, you've misunderstood what I wrote.
Blind adherence to RFCs generally, in my experience, produces garbage
-- the whole point of this process is to produce interoperable
implementations. If you don't bother trying to make your
implementation work with any other implementation, then you're
completely missing the point. You're confusing the map and the
terrain.
I don't equate RFC compliance with semi-functional code. I do equate
the notion of sitting down with a written specification in English,
writing some code, and then shipping it without bothering to see if
any of it works right when run against all available, current
implementations of that specification, or checking to see if the way
in which it operates actually fills the needs of those who'd be using
it to be "semi-functional." You've done only a tiny fraction of the
job.
In other words, you can't do any of this while walling yourself off
from the world.
> > RFCs are by no means a checklist. You won't find a list of
> > "conditional requirements" as you might in some other documents.
>
> Hmm, MUST, SHOULD, MAY sounds like a checklist to me.
You need to read documents from other standards organizations.
> > Note that it says "as a rule" -- not "as the only rule," or even "as
> > the most important rule."
>
> You're splitting hairs a little here.
Nope. I'm pointing out that the "standards" take you only so far.
> It's not about "everyone" or "many different vendors", you only need one BIG
> player to do whatever he wants, regardless of standards and then everyone
> else is "forced" to do the same. Is that a good thing ?
No, it's not a good thing, but it is the way life tends to work.
In *some* cases, there is such a big player, and he'll generally make
the mistakes that others have to follow. In *other* cases, there
isn't such a player. And there are some vendors who are more
cooperative and collaborative than others.
The best case, I think, is that those with prototype implementations
get together at a bake-off and settle the issues before the market
ever sees them. This doesn't always happen, though, nor does it
always catch every important error.
> > the documents that are important -- it's the interoperability of
> > multiple implementations that's important.
>
> No actually it's the interoperability with a few big guys/800 pound gorillas
> implementation that's important.
Get over it. Either you're interested in using equipment from
multiple vendors that all works together, or you're not. Pick one.
> > Hardly. I see a smart developer who understands the rationale as
> > being a peer of the people who wrote the document. Knowing and
>
> I'm talking about not developers who just dismiss some RFC content for no
> good reason except perhaps laziness, plain forgot, or scheduling.
Agreed; those are either merely clumsy (and will correct their errors
in due time) or idiots (and won't). There's no way any standards
organization can turn a bad developer into a good one. Legislating
intelligence or good engineering practice almost never works.
> > Unlike some purported standards processes, I think it's a good thing
> > that RFCs are not considered to be golden references.
> And why exactly ? Do the pros really outweigh the cons ?
Yes. Try working with documents based on those other standards-
setting processes some time. It's an eye-opener.
> > 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.
>
> Of course it's easily understood. If you're a big vendor, you create
> problems and headaches for the other vendors who have to interoperate with
> you regardless of what you are doing.
Wrong answer.
If someone creates interoperability problems by intentionally
violating some part of an RFC, then that person either (a) didn't
fully understand what he was doing, and thus isn't in compliance with
what I wrote above, or (b) is a miscreant. (Obviously, I'm talking
here about intentional violation, not mere bugs or accidents.)
Yes, there are certainly examples of both in the world, but I don't
see that there's anything sensible that the IETF can do about either
case.
I still think you're missing the whole point of the IETF. We're here
to try to create interoperable solutions. That's the shared goal.
Those who are willfully engaged in producing non-interoperable junk
are just not playing the game. They're vandals. Other than perhaps
public humiliation, we don't really have any enforcement powers to
make people "comply" with the IETF.
More to the point: if someone wanted to take a selection of RFCs, and
produce a "walled garden" in which the protocols were almost TCP/IP
but just slightly different and incompatible, there's nothing we can
or will do about it. (In fact there are at least two of those going
on at the moment that I know about. If you're interested, look for
groups trying to set "Internet standards" via bodies other than the
IETF.)
For what it's worth, I'm much more worried about folks who might add
language to the documents that guarantee misunderstandings, who push
proprietary nonsense through the standards process in an attempt to
"bless" their market position, or who push non-answers to non-
problems. Those cases cause far more trouble than the relatively
minor issue of bug-for-bug compatibility.
--
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
|
