Re: RE: AD request / L2 Triggers Charter Statement

Phil Neumiller writes:
> My two cents on this, is that the IETF is not really in a position to affect
> change in L2 standards bodies this way.  By way of contrast, if the IETF
> provided an RFC that defined a packet (or meta-packet) that an L2 layer 
> could send/receive (out-of-band) perhaps to the IP stack, that would be
> extremely useful and provide a nice clean solution to the L2 triggers issue.

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.

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

A revised version of DLPIv2 that covers these signaling mechanisms in
detail would probably make a number of people happy.

> If the IETF wants to stay vague about this very simple concept that is
> OK too, and I will show deference to general consensus.  I felt it was
> important to express my thoughts (and apparantley other folks working
> on other L2s have similar thoughts).

That's the essence of an I-D, and it's certainly the spirit of the
Informational track.  I see no particular need for the IETF to do
this, but since *you* do, you might want to push it along non-
standards track.  (If the idea can't survive outside of the standards
track, then I'm afraid I must not completely understand the issue.)

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