RE: RE: AD request / L2 Triggers Chapter Statement

> From: Einar Vollset <[email protected]>
> To: James Carlson <[email protected]>,
>    Phil Neumiller <[email protected]>
> Cc: <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, Vernon Schryver <[email protected]>


> >> Yes, precisely WHY it needs to be STANDARDIZED!!! You are making
> >> my point for me.  Thanks!
> >
> >Sure, I can see why having interface standards would be nice, but
> >then, why the IETF at all?  Internal implementation details really
> >don't seem to me to be the domain of folks engineering protocols for
> >the Internet itself.
> >
> >This seems more appropriate for The Open Group or some other such OS
> >interfaces standardization body.
>
> I don't see how these triggers can be classified as internal implementation
> details.
> 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?
> 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?

You're missing the nature of standards.  The IEEE does not standardize
nuts and bolts, and ANSI doesn't standarize CSMA/CD networks.  The IETF
standardizes some bits on wires, but not operating system interfaces.
POSIX is not about how many bits are in IP addresses and the IETF is not
about whether the operating system facilities that accept an incoming TCP
connection involve one, two, three, or four system calls.

Application and L2 code affecting routing decisions is decades old,
but still not a topic for the IETF.  As the author of the `routed`
daemon in a bunch of UNIX-like systems including NetBSD, FreeBSD, and
some major commercial UNIX systems, I agree that a standard for such
functions would be nice.  That there are at least four common but
incompatible UNIX ways for something like `routed` to tell the IP code
"add this route" is a royal pain, but it is a pain that has nothing
to do with the IETF.  As someone who has also written network hardware
drivers, I also agree it would be nice if there could be a standard
for how drivers talk to systems, but having dealt with standardized
messes like DLPI, prefer chaos.

To put the point in yet another, albeit offensive way, if you don't
see why the IETF has no business in the businesses oF The Open Group,
POSIX, and the other operating system API, ABI, and other **I groups,
then you probably don't know enough about the issues to be working on
the problem anywhere.  Whatever you come up with might work in a
particular mobile-phone platform, but it won't make the slightest
sense with STREAMS, DLPI, or even a real multi-processor (NUMA) sockets
system that is as BSD-compatible as possible for such a thing, because
you've probably never encountered those issues.

A standards committee is not the right venue for on the job training
about the subject being standardized.


Vernon Schryver    [email protected]

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