RE: RE: AD request / L2 Triggers Chapter Statement

Vernon Schryver <[email protected]> Fri, 7 Jun 2002 16:01:37 -0600 (MDT)
Newsgroups gmane.ietf.pilc
Message-ID <[email protected]>
> From [email protected]  Fri Jun  7 15:27:20 2002

(I didn't trim the bloated cc list not trimmed because I can't what it's
about.)

> ...
> Got to agree with Phil here.  Looking up from layer 2 (my current
> perspective) this is clear and obvious.
> ...


I'm sorry about this flame, but I can't hold it back any longer....

That something is clearly obviously needed does not imply that it
is or is not the business of the IETF.

You guys seem to be confusing the IETF with the ANSI, and demanding
the whole ANSI/ITU/IEEE signal-this and indicate-that inter-state
machine apparatus that is so beloved by those committee's go-ers.

You seem to be equating operating system and host functions with
over-the-wire behavior.  One has always been the concern of the IETF,
but the other has at best very rarely been a successful concern.  The
closest to success I can think of are the ex post facto descriptions
of sockets and at least partly ex post fact IPv6 socket extentions.

If you think you need a way for your layer 2 to tell IP something,
then your best hope is stop talking about IETF working groups and
write some code.  IETF talk is not going to define or implement the
functions you need.  No RFC is going to magically insert code into
your wireless phone operating systems.  Unless your market window
won't close for the next 2 or 3 years, you won't have any relevant
RFCs in time from the IETF.

Do you know so little about current and historic TCP/IP code that you
think that any of them don't already have many L2 triggers, signals,
indications, and other stuff?  Do you imagine that BSD sockets are
the only way for applications to talk to TCP?  Demanding that the IETF
standardize the functions that everyone who has written a network
driver knows about suggests that sort of narrow view.

Asside from fragment assembly, what state machine do hope to set off
with your L2 triggers?  Do you think that RED, ECN, and the other
things that have state machines are in host IP implementations?  When
they are in host implementations, are they in the IP code or in what
you probably consider L2 code?  Does your wireless host IP code have
enough of a state machine for the notion of "trigger" to make any sense?

I suppose instead you want your L2 triggers to reach through IP to
TCP to suggest that TCP do or stop doing or otherwise change.  Don't
you know that people have been doing such things for decades without
the let, leave, or hindrance of the IETF?

Was the WAP Forum such a wonderful success that you want to repeat
the experience inside the IETF?


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/