RE: AD request / L2 Views Problem Statement

Phil, All,

I posted a still largely conceptual draft

http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt

that's related to this discussion...was mostly done before Phil raised this
whole IP underbelly API issue, and is more related to the L2 triggers BOF
that James has been after for some time.

Probably 10x the words required given the content (sorry), but just a bit of
rationale that I wanted to explain.

Regards,

-Scott

> -----Original Message-----
> From: Phil Neumiller [mailto:[email protected]]
> Sent: Tuesday, May 07, 2002 11:27 AM
> To: Eric Whitehill; Scott Corson; [email protected];
> [email protected]; Rex Buddenberg; 
> [email protected]; Dr. Chane
> L. Fullmer; [email protected]; 'William Ivancic';
> [email protected]; [email protected]; [email protected];
> [email protected]; Anders Lindgren; [email protected];
> [email protected]; Armando L. Caro Jr.
> Cc: [email protected]
> Subject: AD request / L2 Views Problem Statement
> 
> 
> Hi Eric,
> 
> I am reluctant to carry on discussions on the pilc list, 
> since I would like confirmation
> from an AD whether they want this discussion here or 
> someplace else.  I assume they
> do, since they relocated the L2 triggers BOF to PILC.   I 
> believe at this point we are
> discussing things within the scope of that planned BOF.  
> 
> AD Request,
> 
> Scott and/or Allison can probably provide clarity here.  I 
> want to express that my 
> desired "perspective" is to position ourselves as link layer 
> designers that want to
> see some standardization on the IP underbelly, i.e. an API if 
> you will, to IPs darker
> side, and a standardized way for IP to send events (at the 
> millisecond time scale)
> "up" to the IP layer.  This means adding standardization to 
> IP, not link layers.  It
> means we want to standardize the way link layers "talk to" IP 
> in the upward
> direction.   The first proposal is a high performance queue 
> for event notification offered
> by the IP layer to bound link layers.  The simplest use of 
> this queue is simply to buffer
> the notifications and forward them to the transport layer if 
> not "hooked" by the IP
> layer.
> 
> With respect to your question Eric, several people have sent 
> comments on the problem
> statement and everything at this point is work-in-progress 
> and everybody is welcome to
> contribute whatever they whenever they can.  Before getting 
> to a formal problem 
> statement, it may prove fruitful to first entertain some 
> philosophical discussions regarding
> the under-specified IP underbelly.  Perhaps many feel that 
> the current underbelly mechanisms
> of arp, rarp, icmp, etc are sufficient for wireless 
> devices???   Maybe the definition of a 
> host/gateway just needs some sprucing up (RFC 1122 / RFC 1123)?
> 
> Best Regards,
> 
> Phil
> 
> 
> ----- Original Message ----- 
> From: "Eric Whitehill" <[email protected]>
> 
> 
> > Phil,
> > 
> > Perhaps I didn't see it, but did everyone agree to the 
> problem statement
> > that you included in 
> > your 4/30 e-mail?
> > 
> > Eric
> > 
> 
> 

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