RE: RE: AD request / L2 Triggers Chapter Statement

Einar Vollset writes:
> I don't see how these triggers can be classified as internal implementation
> details.

On which network interface do these bits appear?  As best I can tell,
they don't.  They go from a network driver up to a network layer (or
perhaps higher).  They don't appear on any external wire.  They are
thus internal.

That argues that these *are* implementation details.  They're subject
to all the usual implementation detail problems: are these messages,
function calls, special dblk types, method invocations, or something
else?  What are the MT issues involved?  How do I send them over
DLPIv2?

Note that if there are multiple different ways to send these things,
depending on implementation particulars (and the charter draft hints
at this by mentioning C and Java bindings, among other things), then
there's much less hope of any sort of interoperability.  All that's
being defined is a "framework" or perhaps a list of requirements, and
not a protocol.  The IETF standardizes protocols.

> If these triggers are used in routing decisions, as they might be in
> mobile IP or MANET scenarions, then why should it be an OS standard?

There are lots of things that are used in routing decisions that are
not part of any possible IETF standard.  For instance, the actual
design of an IP forwarding table is an implementation detail.  It's
not defined by an RFC.  That these things might be used in some direct
or indirect way by forwarding or routing is not an argument to do this
in the IETF.

> It makes sense to me that the there should be clear interfaces to 
> IP on "both sides" of the IP stack.
> Or am I missing something?

I have no substantial disagreement there.  I just don't see how it's
an IETF issue at all.

Should there be variations of this standard for different system
architectures?  That, I think, is the key question.  If you're setting
up something that defines some sort of application interface, *and*
that interface cannot somehow be the same on all systems, then I
really question the value of doing that, at least within the IETF.
Part of the goodness of existing IETF standards is that they're
agnostic with respect to operating system architecture.  You can
implement TCP/IP as a part of the kernel, as a STREAMS module, or even
as an application program, and the only thing that really matters (for
interoperability) is whether the bits on the wire follow the standard.

What would be the value of setting an interface standard that is
either (a) so vague that nobody can follow it exactly and nobody can
port to it and hope to have an interoperable implementation or (b) so
precise that it works only on a tiny subset of all systems out in the
real world and thus can't be used by interoperable implementations?

What bothers me more about this charter is that it seems to assume
that wireless links have requirements that are somehow novel for
IP-based systems.  This is essentially false.  Thus, not only is this
something that the IETF can't solve, it's very likely to be something
that the IETF doesn't have to solve.  Those who know how to build
robust systems will continue to do so, those who do not, will not.

Has any work been done to determine how previous generations with the
very same requirements have solved the problems?  What I see in the
draft is a discussion of this chosen solution, but no discussion of
prior art.

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