Re: RE: AD request / L2 Triggers Charter Statement

Hi James,

> Yes, sounds like what you've been advocating all along.  However, it's
> still a non-starter: these "meta-packets" would appear only between
> the L2 implementation and the IP implementation on a given host.
> They're thus not testable or observable outside of that host and are
> local design and/or architectural details.

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.  Over the years it seems that the IETF matured
to the point of almost completely specifying the IP to Ethernet binding.  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?  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...
> 
> > Even if the IP layer simply provided a reflector service for these meta-
> > packets for subscribed  transports it would add huge amounts of flexibility
> > that must currently be done in proprietary ways. 
> 
> Sure.  But it's still a system design issue, and not a TCP/IP protocol
> issue.  The former is certainly a fascinating and useful area, and
> obviously very important for many (or most) TCP/IP implementors, but
> it's just not the focus of the IETF.  IETF documents tend to tell
> people what the system must do in order to interoperate, and quite
> intentionally leave out *how* it must be done.

Yet inter-operating with multiple L2s is somehow deemed NOT useful?
It is an area that huge amounts of proprietary code is written to do the
same thing over and over again, right?  Some use this as a prototypical example
of software developer pork barrelling.  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...

Best regards,

Phil


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