Re: RE: AD request / L2 Triggers Chapter Statement

Hello Vernon,

BTW, the bloated CC list, is the list of co-authors for L2 triggers BOF
problem statement and drafts.  These are the folks that have volunteered
their precious time and expressed deep interest in this matter.

> 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 have been following closely, you will have noticed that I did indeed
mention sockets.  In fact sockets is a top down approach.  I advocate a more
object oriented approach where the IP stack have member functions on
all sides, especially the dark underbelly where all the hidden art is.  I am
really tired have to wade through dozens of "ingenious implementations".

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

Hmm.  That is why we are having a BOF.  That is the first step in creating
a WG that will in turn create drafts and hopefully an RFC.  I really don't
get your point.  2-3 years is probably OK, but I have seen some things
move faster then that.

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

Then you agree its an underspecified black art.  Perhaps it give you job
security.  It just gives me a headache each time I need to interface another
L2 to IP.

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

What we are asking for is the interface and some rudimentary behavior.  
We believe that putting in the standardized doorway is the first step.

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

Yes, precisely WHY it needs to be STANDARDIZED!!! You are making
my point for me.  Thanks!

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

I am not sure how/why you mention WAP.  We have nothing to do with
WAP.  Could you explain your mentioning of WAP?

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/