Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Tue, 28 Jan 2003 18:01:27 -0500

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Tuesday, January 28, 2003 2:55 PM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: RE: PPP over Sonet default MRU
> 
> 

> 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 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. 

> 
> 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 ?

> 
> 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.

> (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.)

Come on, we want the names !!!

> > "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."

You're splitting hairs a little here.

> 
> 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.

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 ?

> 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.

> > > 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

I'm talking about not developers who just dismiss some RFC content for no
good reason except perhaps laziness, plain forgot, or scheduling.

> 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 ?

>  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. 

> 
> > <!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

Yes. And as I have previously explained to you, as much as I keep sending in
"plain ascii text" it still gets out with some HTML. Still I'm sure this can
be filtered out at the input if it causes discomfort or confusion.

Steph

---

From: James Carlson <[email-masked]>
Date: Wed, 29 Jan 2003 11:20:41 -0500

> I'll have to look at your bank account before I decide whether or not you

I find that comment completely baffling.

For what it's worth, and it's not much, my bank account is certainly
*not* large.

> Having seen "The planet of the apes", I'd rather not let 800 pound gorillas

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.

> Why would it be semi-functional ? Do you equate RFC compliance with

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.

> Hmm, MUST, SHOULD, MAY sounds like a checklist to me.

You need to read documents from other standards organizations.

> You're splitting hairs a little here.

Nope.  I'm pointing out that the "standards" take you only so far.

> 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.

> 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.

> 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.

> 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.

> 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         <[email-masked]>
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