Re: RE: AD request / L2 Triggers Charter Statement

Phil Neumiller writes:
> Its ironic that the IETF is more than willing to specify what bits should be
> in the payload of an L2 device and on a wire (that they can't directly touch)
> but not be willing to communicate with an L2 device (which they can directly
> touch) in any standard way.

I think you're confusing two very different things here:

	- the documents that are standardized via the IETF

	- the work that folks do to make useful systems

The two are quite different.  Just because people have to do any
number of special efforts in design or implementation of any part of
TCP/IP does *not* make all of those efforts into IETF standards
issues.

The problem is that system designs vary by much more than I (or
probably anyone else on this list) can possibly comprehend.  The IETF
is not a software interface standards group.  It's really not.  There
are many such groups -- X/Open being one that has been cited here
before.  Linus Torvalds perhaps being another.  ;-}

The point is that there's no such thing as One True System
Architecture.  Perhaps, if one is stuck writing software for a
particularly ubiquitous O/S, it might seem that way, but it's just not
true.

Worse still, the IETF's structure is really not set up to handle such
issues.  The IETF (and the IESG) have fair cross-sections of folks who
build IP-speaking devices for a living, but the folks who do system
interfaces for a living don't all participate here.  They're off in
the appropriate standards bodies.

>  Over the years it seems that the IETF matured
> to the point of almost completely specifying the IP to Ethernet binding.

No.  It specifies where the bits belong inside the Ethernet frames.
That's all it can specify.  It doesn't specify whether the hardware
interface is interrupt-driven or polled, whether the driver is single
or multithreaded, whether the entrance to the IP stack is an upcall, a
BSD soft interrupt, or a DLPIv2 STREAMS M_PROTO message.

It doesn't, and I'm arguing that it can't and must not.

>  If
> we use the OO concept of inheritance, or design patterns, isn't logical that
> one would seek commonalities between L2 to IP bindings and standardize
> this?

Seeking the commonality, and documenting the necessary bits and the
known good practices (or at least the possible alternatives) all seem
like mostly good things.  Unfortunately, I see no hope at all of
"standardizing" any such thing.

What external test do you apply to show that some vendor has followed
a design practice?

>  It seems that just some maturing of the relationship between L2s and the
> IP layer is needed here.  For some reason, I think this will eventually happen.
> It may take a long while though...

On a given system architecture, this can be done.  The IETF doesn't
just support one particular design philosophy, no matter how "good" it
might seem right now.  Design strategies are passing fads that come
and go; protocols are forever.

> Yet inter-operating with multiple L2s is somehow deemed NOT useful?

Correct.  That's not interoperability.  That's perhaps "system design"
or "code reuse" or "making things easier for third party integration."
It's not interoperability by any stretch of IETF terms.  There's only
one party involved as far as the IETF is concerned; the system itself
is a node on an IP network.  Saying that you ought to be internally
interoperable with yourself is probably axiomatic.

> It is an area that huge amounts of proprietary code is written to do the
> same thing over and over again, right?

You bet.

>  Some use this as a prototypical example
> of software developer pork barrelling.

Ha!  If only it were that simple!

"Hello, I'd like to put the turbocharger from my wife's V70 on my
325i.  What do you mean I can't do that?  Aren't there any standards
for cars?"

>  A whole cottage industry has developed
> around the black art of device drivers and their intricate details.  I have even
> written a few myself over the years.  This is definitely an underspecified and
> under-standardized area of networking art.  Maybe I am way off in the
> weeds here.  I think I have expressed my arguments now the best I can.
> I think I will be quiet for while.... :-)  We can only hope...

Break out the scythe.  ;-}

Unless I miss my guess, you're proposing a standard internal low-level
("kernel") *software* interface (and corresponding assumptions about
system architecture) that'll work on Windows, Solaris, Linux, *BSD,
AIX, VMS, MVS, VxWorks, IOS, and others.  "Weeds" don't come to mind
here.  "Windmills" do.  :-/

-- 
James Carlson, Solaris Networking         <[email protected]>
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

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/